Re: Sender header?

[prj@po.cwru.edu (Paul Jarc)]

Stainless Steel Rat <ratinox@peorth.gweep.net> 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