* (gnus-inews-domain-name); insertion of Sender: @ 1996-01-18 11:49 Per Persson 1996-01-18 13:37 ` Per Abrahamsen 0 siblings, 1 reply; 17+ messages in thread From: Per Persson @ 1996-01-18 11:49 UTC (permalink / raw) Cc: gnus-bug 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-18 11:49 (gnus-inews-domain-name); insertion of Sender: Per Persson @ 1996-01-18 13:37 ` Per Abrahamsen 1996-01-18 15:36 ` Per Persson 0 siblings, 1 reply; 17+ messages in thread From: Per Abrahamsen @ 1996-01-18 13:37 UTC (permalink / raw) Cc: gnus-bug 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-18 13:37 ` Per Abrahamsen @ 1996-01-18 15:36 ` Per Persson 1996-01-19 8:34 ` Per Abrahamsen 0 siblings, 1 reply; 17+ messages in thread From: Per Persson @ 1996-01-18 15:36 UTC (permalink / raw) Cc: ding, gnus-bug 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-18 15:36 ` Per Persson @ 1996-01-19 8:34 ` Per Abrahamsen 1996-01-19 10:14 ` Per Persson 0 siblings, 1 reply; 17+ messages in thread From: Per Abrahamsen @ 1996-01-19 8:34 UTC (permalink / raw) Cc: gnus-bug >>>>> "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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 8:34 ` Per Abrahamsen @ 1996-01-19 10:14 ` Per Persson 1996-01-19 10:14 ` Per Abrahamsen 0 siblings, 1 reply; 17+ messages in thread From: Per Persson @ 1996-01-19 10:14 UTC (permalink / raw) Cc: ding, gnus-bug 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 10:14 ` Per Persson @ 1996-01-19 10:14 ` Per Abrahamsen 1996-01-19 13:29 ` Per Persson 0 siblings, 1 reply; 17+ messages in thread From: Per Abrahamsen @ 1996-01-19 10:14 UTC (permalink / raw) Cc: gnus-bug >>>>> "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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 10:14 ` Per Abrahamsen @ 1996-01-19 13:29 ` Per Persson 1996-01-19 14:22 ` Per Abrahamsen 0 siblings, 1 reply; 17+ messages in thread From: Per Persson @ 1996-01-19 13:29 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 13:29 ` Per Persson @ 1996-01-19 14:22 ` Per Abrahamsen 1996-01-19 18:05 ` Sten Drescher 0 siblings, 1 reply; 17+ messages in thread From: Per Abrahamsen @ 1996-01-19 14:22 UTC (permalink / raw) >>>>> "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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 14:22 ` Per Abrahamsen @ 1996-01-19 18:05 ` Sten Drescher 1996-01-19 20:38 ` Per Abrahamsen 0 siblings, 1 reply; 17+ messages in thread From: Sten Drescher @ 1996-01-19 18:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 18:05 ` Sten Drescher @ 1996-01-19 20:38 ` Per Abrahamsen 1996-01-19 22:37 ` Sten Drescher ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Per Abrahamsen @ 1996-01-19 20:38 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 20:38 ` Per Abrahamsen @ 1996-01-19 22:37 ` Sten Drescher 1996-01-20 1:46 ` Stainless Steel Rat 1996-01-19 22:55 ` Sten Drescher 1996-01-20 5:24 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 17+ messages in thread From: Sten Drescher @ 1996-01-19 22:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 22:37 ` Sten Drescher @ 1996-01-20 1:46 ` Stainless Steel Rat 1996-01-20 11:08 ` Sudish Joseph 0 siblings, 1 reply; 17+ messages in thread From: Stainless Steel Rat @ 1996-01-20 1:46 UTC (permalink / raw) -----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/ \ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-20 1:46 ` Stainless Steel Rat @ 1996-01-20 11:08 ` Sudish Joseph 0 siblings, 0 replies; 17+ messages in thread From: Sudish Joseph @ 1996-01-20 11:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 20:38 ` Per Abrahamsen 1996-01-19 22:37 ` Sten Drescher @ 1996-01-19 22:55 ` Sten Drescher 1996-01-19 23:53 ` Per Abrahamsen 1996-01-20 5:24 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 17+ messages in thread From: Sten Drescher @ 1996-01-19 22:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 22:55 ` Sten Drescher @ 1996-01-19 23:53 ` Per Abrahamsen 1996-01-20 2:30 ` Sten Drescher 0 siblings, 1 reply; 17+ messages in thread From: Per Abrahamsen @ 1996-01-19 23:53 UTC (permalink / raw) >>>>> "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 :-). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 23:53 ` Per Abrahamsen @ 1996-01-20 2:30 ` Sten Drescher 0 siblings, 0 replies; 17+ messages in thread From: Sten Drescher @ 1996-01-20 2:30 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: (gnus-inews-domain-name); insertion of Sender: 1996-01-19 20:38 ` Per Abrahamsen 1996-01-19 22:37 ` Sten Drescher 1996-01-19 22:55 ` Sten Drescher @ 1996-01-20 5:24 ` Lars Magne Ingebrigtsen 2 siblings, 0 replies; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 1996-01-20 5:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1996-01-20 11:08 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-01-18 11:49 (gnus-inews-domain-name); insertion of Sender: Per Persson 1996-01-18 13:37 ` Per Abrahamsen 1996-01-18 15:36 ` Per Persson 1996-01-19 8:34 ` Per Abrahamsen 1996-01-19 10:14 ` Per Persson 1996-01-19 10:14 ` Per Abrahamsen 1996-01-19 13:29 ` Per Persson 1996-01-19 14:22 ` Per Abrahamsen 1996-01-19 18:05 ` Sten Drescher 1996-01-19 20:38 ` Per Abrahamsen 1996-01-19 22:37 ` Sten Drescher 1996-01-20 1:46 ` Stainless Steel Rat 1996-01-20 11:08 ` Sudish Joseph 1996-01-19 22:55 ` Sten Drescher 1996-01-19 23:53 ` Per Abrahamsen 1996-01-20 2:30 ` Sten Drescher 1996-01-20 5:24 ` Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).