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

[Sten Drescher <stend@grendel.texas.net>]

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.