From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4828 Path: main.gmane.org!not-for-mail From: Sten Drescher Newsgroups: gmane.emacs.gnus.general Subject: Re: (gnus-inews-domain-name); insertion of Sender: Date: 19 Jan 1996 16:55:03 -0600 Organization: Tandem Computers Sender: dreschs@mpd.tandem.com Message-ID: <55ybr323so.fsf@galil.austnsc.tandem.com> References: <199601181337.OAA28961@ssv4.dina.kvl.dk> <199601190834.JAA01129@ssv4.dina.kvl.dk> <199601191014.LAA01179@ssv4.dina.kvl.dk> <199601191422.PAA01295@ssv4.dina.kvl.dk> <5568e82h73.fsf@galil.austnsc.tandem.com> <199601192038.VAA01777@ssv4.dina.kvl.dk> Reply-To: Sten Drescher NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1035145521 30978 80.91.224.250 (20 Oct 2002 20:25:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:25:21 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.7.3/8.6.9) with SMTP id PAA04376 for ; Fri, 19 Jan 1996 15:48:54 -0800 Original-Received: from galil.austnsc.tandem.com (kneehigh.mpd.tandem.com [131.124.250.14]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 19 Jan 1996 23:56:01 +0100 Original-Received: (from dreschs@localhost) by galil.austnsc.tandem.com (8.7.1/8.7.1) id QAA06780; Fri, 19 Jan 1996 16:55:09 -0600 (CST) Original-To: ding@ifi.uio.no In-Reply-To: Per Abrahamsen's message of Fri, 19 Jan 1996 21:38:43 +0100 Original-Lines: 73 Xref: main.gmane.org gmane.emacs.gnus.general:4828 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4828 Per Abrahamsen 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> 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 /* 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.