(gnus-inews-domain-name); insertion of Sender:

(gnus-inews-domain-name); insertion of Sender:

[Per Persson]

I've started playing around with having a different domain in 'From:'
compared to the real domain I'm posting from. I can't find a decent
way to set this up so I Get a real 'Sender:' header, the "best"
attempt gave me 'From: pp@pfawww.pp.se' and 'Sender:
pp@sunny.pfawww.pp.se' when it should have been 'Sender:
pp@sunny.bahnhof.se'. Does someone have any ideas on how I could
accomplish this or perhaps 'fix' this in (september)GNUS?

I'm also a bit curious about gnus-msg.el's
(gnus-inews-insert-headers), espescially the part about insertion of
the 'Sender:' header. Shouldn't line 1208 (in v0.26) be:

                 (gnus-check-before-posting 'sender)

instead of:

                 (not (gnus-check-before-posting 'sender))

Perhaps I've misunderstood the function, but that's what I would like
it to be anyway. :-)

Oh, almost forgot to report the other bug: When I relpy/followup to a
mail in a nnfolder group I don't get that first line added... the one
that goes:

in article <sdjfklasdfj23478@i.suck.nuts> God <god@heaven.org> wrote:

After I've reply/followup'ed in a real newsgroup once it works in
nnfolders as well... dunno if this bug has been fixed in the more
recent versions... but...

... I've been unsubscribed to ding-l for a few months, by accident,
but now I'm back again!

-- 
anum meum aperies, asperge me spermate tuo et inquinabor
url; http://pfawww.pp.se/~pp/   email; <pp@pfawww.pp.se>
phone#'s;  work/home/fax: +46 (0)18 100899/247473/103737

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Abrahamsen]

You shouldn't try to modify "Sender:", it isn't expected to reflect
your real email address or provide any information for ordinary users.
Sender: is there only for debuging and half-hearted authorization.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Persson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>You shouldn't try to modify "Sender:", it isn't expected to reflect
>your real email address or provide any information for ordinary users.
>Sender: is there only for debuging and half-hearted authorization.

Well... if I set everything up the "right" way to get
<pp@pfawww.pp.se> the 'Sender:' get set to <pp@sunny.pfawww.pp.se>
when it should be <pp@sunny.bahnhof.se> as 'pfawww.pp.se' only is a
virtual domain over bahnhof.se... Why add a header that has the
potential to be wrong if it's supposed to be authorization? That
doesn't sound more half-stupid then half-hearted to me.

-- 
anum meum aperies, asperge me spermate tuo et inquinabor
url; http://pfawww.pp.se/~pp/   email; <pp@pfawww.pp.se>
phone#'s;  work/home/fax: +46 (0)18 100899/247473/103737

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Abrahamsen]

>>>>> "PP" == Per Persson <pp@pfawww.pp.se> writes:

PP> Why add a header that has the
PP> potential to be wrong if it's supposed to be authorization? 

It shows who the *software* believes the sender is, in case the *user*
by accident or deliberately uses a bogus address.  Making it easy
customizable would remove what little use it has.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Persson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>It shows who the *software* believes the sender is, in case the *user*
>by accident or deliberately uses a bogus address.  Making it easy
>customizable would remove what little use it has.

Then why does the *software* use variables the *user* can set himself?

/pp.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Abrahamsen]

>>>>> "PP" == Per Persson <pp@pfawww.pp.se> writes:

PP> Then why does the *software* use variables the *user* can set himself?

Cause the software has no choice.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Persson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>Cause the software has no choice.

So using a half-hearted/intelligent authentication method which might
return bogus values is better then letting the user make sure that the
value returned is correct? Thanks for clearing things out for me.

/pp.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Abrahamsen]

>>>>> "PP" == Per Persson <pp@pfawww.pp.se> writes:

PP> So using a half-hearted/intelligent authentication method which might
PP> return bogus values is better then letting the user make sure that the
PP> value returned is correct? Thanks for clearing things out for me.

A value provided by the user is per definition wrong for the Sender:
field.  The Sender: field is not expected to reflect the users mail
address.  That would have been really stupid, as we already have the
From: field for that.

Re: (gnus-inews-domain-name); insertion of Sender:

[Sten Drescher]

Per Abrahamsen <abraham@dina.kvl.dk> said:

>>>>>> "PP" == Per Persson <pp@pfawww.pp.se> writes:
PP> So using a half-hearted/intelligent authentication method which
PP> might return bogus values is better then letting the user make sure
PP> that the value returned is correct? Thanks for clearing things out
PP> for me.

PA> A value provided by the user is per definition wrong for the Sender:
PA> field.  The Sender: field is not expected to reflect the users mail
PA> address.  That would have been really stupid, as we already have the
PA> From: field for that.

	Incorrect.  It _must_ reflect the users mail address if it is
present:

rfc822> 4.1.  SYNTAX

[...]

rfc822> authentic   =   "From"       ":"   mailbox  ; Single author
rfc822>             / ( "Sender"     ":"   mailbox  ; Actual submittor
rfc822>                 "From"       ":" 1#mailbox) ; Multiple authors
rfc822>                                             ;  or not sender

[...]

rfc822> 4.4.2.  SENDER / RESENT-SENDER

rfc822> This field contains the authenticated identity of the AGENT
rfc822> (person, system or process) that sends the message.  It is
rfc822> intended for use when the sender is not the author of the mes-
rfc822> sage, or to indicate who among a group of authors actually sent
rfc822> the message.  If the contents of the "Sender" field would be
rfc822> completely redundant with the "From" field, then the "Sender"
rfc822> field need not be present and its use is discouraged (though
rfc822> still legal).  In particular, the "Sender" field MUST be present
rfc822> if it is NOT the same as the "From" Field.

-- 
#include <disclaimer.h>				/* Sten Drescher */
1973 Steelers    About Three Bricks Shy of a Load    1994 Steelers
1974 Steelers         And the Load Filled Up         1995 Steelers?
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3
Unsolicited email advertisements will be proofread for a US$100/page fee.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Abrahamsen]

Try to read what `Son-of-RFC 1036' has to say about sender.  

As I read it: If the user provide a from it can't verify, the software
should provide as good a sender it can without using (unverifiable)
input from the user.

<URL:http://www.ifi.uio.no/~larsi/notes/son-of-rfc1036.txt>

Re: (gnus-inews-domain-name); insertion of Sender:

[Sten Drescher]

Per Abrahamsen <abraham@dina.kvl.dk> said:

PA> Try to read what `Son-of-RFC 1036' has to say about sender.

PA> As I read it: If the user provide a from it can't verify, the
PA> software should provide as good a sender it can without using
PA> (unverifiable) input from the user.

PA> <URL:http://www.ifi.uio.no/~larsi/notes/son-of-rfc1036.txt>

	So Son-of-RFC 1036 is discarding its RFC 822 heritage on this
issue?  This is a problem for Gnus, since it needs to adhere to both
standards.

-- 
#include <disclaimer.h>				/* Sten Drescher */
1973 Steelers    About Three Bricks Shy of a Load    1994 Steelers
1974 Steelers         And the Load Filled Up         1995 Steelers?
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3
Unsolicited email advertisements will be proofread for a US$100/page fee.

Re: (gnus-inews-domain-name); insertion of Sender:

[Sten Drescher]

Per Abrahamsen <abraham@dina.kvl.dk> said:

PA> Try to read what `Son-of-RFC 1036' has to say about sender.

PA> As I read it: If the user provide a from it can't verify, the
PA> software should provide as good a sender it can without using
PA> (unverifiable) input from the user.

PA> <URL:http://www.ifi.uio.no/~larsi/notes/son-of-rfc1036.txt>

	Not exactly.  Son-of-RFC 1036 has a provision for user-supplied
sender information, and superceding that when it is inconsistient with
information retrieved from the system.  Here's a relevant snippet:

sorfc1036> If the poster supplies a From header, the posting agent MUST
sorfc1036> ensure that a Sender header is present, unless it can verify
sorfc1036> that the mailing address in the From header is a valid mail-
sorfc1036> ing address for the poster.  A poster-supplied Sender header
sorfc1036> MAY be used, if its mailing address is verifiably a valid
sorfc1036> mailing address for the poster; otherwise the posting agent
sorfc1036> MUST supply a Sender header and delete (or rename, e.g.  to
sorfc1036> X-Unverifiable-Sender) any poster-supplied Sender header.

sorfc1036> Note: It might be useful to preserve a poster-supplied Sender
sorfc1036> header so that the poster can supply the full-name part of
sorfc1036> the content.  The mail- ing address, however, must be right.
sorfc1036> Hence, the posting agent must generate the Sender header if
sorfc1036> it is unable to verify the mailing address of a
sorfc1036> poster-supplied one.

sorfc1036> NOTE: NNTP implementors, in particular, are urged to note
sorfc1036> this requirement (which would eliminate the need for ad hoc
sorfc1036> headers like NNTP-Posting- Host), although there are
sorfc1036> admittedly some imple- mentation difficulties.  A user name
sorfc1036> from an RFC 1413 server and a host name from an inverse map-
sorfc1036> ping of the address, perhaps with a "full name" comment
sorfc1036> noting the origin of the information, would be at least a
sorfc1036> first approximation:

sorfc1036> Sender: fred@zoo.toronto.edu (RFC-1413@reverse-lookup; not verified)

sorfc1036> While this does not completely meet the specs, it comes a lot
sorfc1036> closer than not having a Sender header at all.  Even just
sorfc1036> supplying a placeholder for the user name:

sorfc1036> Sender: somebody@zoo.toronto.edu (user name unknown)

sorfc1036> would be better than nothing.

	This indicates to me that allowing a user variable for the
Sender is appropriate, but that Gnus should supercede it (while still
including it via X-Unverifiable-Sender) if it doesn't match up with as
much as Gnus can automatically retrieve.  I.e., I use a From of
stend@grendel.texas.net, even though I'm posting/mailing from
dreschs@galil.austnsc.tandem.com.  If I set gnus-user-sender-line to
stend@grendel.texas.net, Gnus should replace that with what it can
determine to be the sender.  If it is dreschs@austnsc.tandem.com, Gnus
should leave it alone, since the username matches and the domain portion
is a subdomain of the FQDN.  If it is stend@cris.com, Gnus should move
that to X-Unverifiable-Sender, and generate a Sender header.

	Of course, I can always configure my system to believe that it
is msn.com, and create a user billgates, but there's not much that can
be done about that.

-- 
#include <disclaimer.h>				/* Sten Drescher */
1973 Steelers    About Three Bricks Shy of a Load    1994 Steelers
1974 Steelers         And the Load Filled Up         1995 Steelers?
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3
Unsolicited email advertisements will be proofread for a US$100/page fee.

Re: (gnus-inews-domain-name); insertion of Sender:

[Per Abrahamsen]

>>>>> "SD" == Sten Drescher <stend@grendel.texas.net> writes:

SD> If it is dreschs@austnsc.tandem.com, Gnus
SD> should leave it alone, since the username matches and the domain portion
SD> is a subdomain of the FQDN. 

I don't see any justification for that, it would make sender fields
like user@edu or user@ac.uk for academic users in US and UK.

Of course, if Gnus made an SMTP connection to the subdomain host and
issued a VRFY user, that would make it OK :-).

Re: (gnus-inews-domain-name); insertion of Sender:

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "SD" == Sten Drescher <stend@grendel.texas.net> writes:

SD> 	So Son-of-RFC 1036 is discarding its RFC 822 heritage on this
SD> issue?

No, it superceeds RFC 822, rendering parts of it obsolete.  This is the
nature of evolving standards.  You will find many such documents in the
RFC archives.  RFC 822 has about a half-dozen or so current RFCs that
partially superceed parts of it, and a number of them fully superceed
previous versions of themselves.  Look at the MIME and PEM RFCs sometime.

SD> This is a problem for Gnus, since it needs to adhere to both
SD> standards.

No, it needs to adhere to the most recently defined standard.  If it can
also adhere to the earlier standards for backwards compatability then
great, but in this case it is not required.

From: ratinox@ccs.neu.edu To: ding@ifi.uio.no Message-ID:
<srivi7mydu.fsf@delphi.ccs.neu.edu> Date: 19 Jan 1996 20:46:21 -0500 Subject:
Re: (gnus-inews-domain-name); insertion of Sender:

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMQBJbZ6VRH7BJMxHAQEpvwQApnaANqCBS4VBeC3Rj1e1WhTYBp1ahljt
WqYQu9z874GpmiW7jEy1+ZiPLQkzGbH6nwOTNv0wC2rdm4nOkrNl6aG2JkrYHNfI
QFchUdsxFLQJVfr050vJKskKxFKEmq6HGrNOf7gEtsyPKvbMeJi3RCUlP514hryC
waGfbno9N/U=
=K8cz
-----END PGP SIGNATURE-----
-- 
Rat <ratinox@ccs.neu.edu>          \ Do not taunt Happy Fun Ball.
PGP Public Key: Ask for one today!  \ 
http://www.ccs.neu.edu/home/ratinox/ \ 

Re: (gnus-inews-domain-name); insertion of Sender:

[Sten Drescher]

Per Abrahamsen <abraham@dina.kvl.dk> said:

>>>>>> "SD" == Sten Drescher <stend@grendel.texas.net> writes:

SD> If it is dreschs@austnsc.tandem.com, Gnus should leave it alone,
SD> since the username matches and the domain portion is a subdomain
SD> of the FQDN.

PA> I don't see any justification for that, it would make sender
PA> fields like user@edu or user@ac.uk for academic users in US and
PA> UK.

	I see the problem here );.

PA> Of course, if Gnus made an SMTP connection to the subdomain host
PA> and issued a VRFY user, that would make it OK :-).

	Yes, but I'm not sure we want to burden Gnus with that.  I
guess that if the host portion of the email address doesn't match a
FQDN of the sending host, it should be superceded.

-- 
#include <disclaimer.h>				/* Sten Drescher */
1973 Steelers    About Three Bricks Shy of a Load    1994 Steelers
1974 Steelers         And the Load Filled Up         1995 Steelers?
Unsolicited email advertisements will be proofread for a US$100/page fee.

Re: (gnus-inews-domain-name); insertion of Sender:

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> As I read it: If the user provide a from it can't verify, the software
> should provide as good a sender it can without using (unverifiable)
> input from the user.

Indeed.  The reason Gnus sometimes get the Sender header wrong is that
`(system-name)' on some machines (notably Suns) does not return a
fully qualified name -- which means that Gnus has to do some guessing.
And it guesses based on the variables it has available.

Perhaps Gnus shouldn't do that, though.  I've now changed the Sender
to *always* use `(system-name)', whether it looks ok or not.  That way
it's more difficult for the user to influence the header (which is
good), but it'll be "wrong" (i. e., not fully qualified) more often
(which is bad).

-- 
Home is where the cat is.

Re: (gnus-inews-domain-name); insertion of Sender:

[Sudish Joseph]

Stainless Steel Rat writes:
>>>>>> "SD" == Sten Drescher <stend@grendel.texas.net> writes:

SD> So Son-of-RFC 1036 is discarding its RFC 822 heritage on this
SD> issue?

> No, it superceeds RFC 822, rendering parts of it obsolete.  This is the

822 applies to mail messages, 1036 to news messages.  Neither one can
obsolete the other.  However, 1036 does refer back to 822 on several
issues.

> previous versions of themselves.  Look at the MIME and PEM RFCs sometime.

I don't know about PEM, but MIME certainly doesn't supercede RFC822;
for one thing, MIME deals with the format of the message body while
822 concerns itself with headers. 

SD> This is a problem for Gnus, since it needs to adhere to both
SD> standards.

> No, it needs to adhere to the most recently defined standard.  If it can
> also adhere to the earlier standards for backwards compatability then
> great, but in this case it is not required.

I agree with Sten.  Gnus must follow 822 for mail and 1036 for news.

Also, I agree with the original poster in this thread.  It's silly to
use a user-supplied string for Sender:, especially when Gnus isn't
checking this address in the manner that So1036 specifies.  Why not
simply use (system-name), throwing in the towel if this returns
gibberish.  If misconfiguration at the concerned site renders
system-name useless, Gnus has no way of providing a Sender: header
that satisfies So1036 (short of emulating sendmail)--so why insert
one?

-Sudish