From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/36360 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: Sender header? Date: 24 May 2001 16:48:27 -0400 Sender: prj@multivac.cwru.edu Message-ID: References: <01May23.141128edt.115245@gateway.intersys.com> <01May24.115917edt.115250@gateway.intersys.com> <01May24.143521edt.115214@gateway.intersys.com> <01May24.153439edt.115213@gateway.intersys.com> <01May24.163305edt.115259@gateway.intersys.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035171959 8190 80.91.224.250 (21 Oct 2002 03:45:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:45:59 +0000 (UTC) Return-Path: Original-Received: (qmail 28458 invoked by alias); 24 May 2001 20:48:27 -0000 Original-Received: (qmail 28453 invoked from network); 24 May 2001 20:48:27 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (261@129.22.96.25) by gnus.org with SMTP; 24 May 2001 20:48:27 -0000 Original-Received: (qmail 26515 invoked by uid 500); 24 May 2001 20:48:49 -0000 Mail-Followup-To: ding@gnus.org Original-To: "\(ding\)" In-Reply-To: <01May24.163305edt.115259@gateway.intersys.com> (Stainless Steel Rat's message of "Thu, 24 May 2001 16:32:48 -0400") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 Original-Lines: 66 Xref: main.gmane.org gmane.emacs.gnus.general:36360 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:36360 Stainless Steel Rat writes: > * prj@po.cwru.edu (Paul Jarc) on Thu, 24 May 2001 >| But your interpretation requires more than that. It's not enough just >| to give random-sending-host.domain.com an MX record pointing to >| mail.domain.com - mail.domain.com must also accept mail explicitly >| addressed to random-sending-host.domain.com, even if it would >| otherwise only accept mail addressed to domain.com itself, because you >| would put random-sending-host.domain.com in Sender, and Sender must be >| a mailbox of the person who sends the message. > > Yes, it should. In fact, it must. That is the nature of DNS. It is not the nature of DNS (or anything else) that the mail exchanger for domain.com must also accept mail for any other domain, such as random-sending-host.domain.com. >| Where does 2822 say that Sender must identify the host used to send >| the mail? > > The canonical mailbox is required by RFC 2822. I didn't ask you to restate the requirement. I asked where it was. RFC 2822 does not use the word "canonical" in connection with Sender. I haven't been able to find the requirement. > login @ FQDN is the most canonical name for any given user. It isn't a canonical address if it isn't an address at all. It also isn't known to be canonical at all - it's merely the only possible address that can be determined automatically. user-mail-address is extremely more likely to be the user's canonical address. A user's canonical address does not depend on what machine ey happens to be using at the moment. >| > Proper mail handling depends on that being the case. >| What breaks when Sender does not identify the host the mail was sent >| from? > > The correct question is, what breaks the Sender field does not canonically > identify the sender? No, it isn't. You're demanding that Sender identify not just the person who sent the message, but also the host it was sent from. So I ask, what will break if your additional requirement isn't met? > You see, Sender is for human consumption only. It exists at least > partially so that humans, like me, can track down problems at their > source. I can't find any support for that statement in RFC 2822. > If the Sender field does not include the FQDN of the sending host > it makes finding and solving problems that much more difficult. You still have Received fields. Sender is unreliable anyway, since it's under the control of a possible malicious person. >| Right, but the A and MX records aren't the problem. > > Correct, they are the solution. They are necessary, but not sufficient, to make your requirement work. paul