In
<C6DDA43B91BFDA49AA2F1E473732113E5DBB76(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
The set of 'identities' to which the authentication credential may be bound
is relatively small and all provide value.
Andy asks for which identities won't conflict with RFC2821/2822, and I
have some comments on what PHB says, so this is kind of a two-fer post.
2821 HELO If this resolves to a domain name there is no reason why it
should not be consistent in a legitimate mail.
RFC2821 section 4.1.4 says, in part, the following:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Now, in my opinion, validating the HELO domain using both the IP address
*and* MARID info means that we can reject invalid HELO domains without
violating RFC2821. If I recall correctly, some people in the "Input
on identities" thread disagree.
2821 FROM If this is present (i.e. not a bounce) the only reason
it might be inconsistent in a legitimate email is that
it was forwarded.
I know of no problems with validating the MAIL FROM, nor do I think
that requiring forwarders to change to using their own domain when
forwarding is in violation of any RFC.
2822 Sender If present there is no reason this should not be consistent.
Non-compliant forwarders should get in compliance.
This, I'm not so sure about.
RFC2822 section 3.6.2. "Originator fields" says, in part, the following:
The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
In the case of mailing lists, I can see how the emails can be
considered "new" messages and the mailing list manager is the agent
responsible for the actual transmission of the message.
In the case of mail forwarders, requiring them to replace the Sender:
header with something that matches their IP address seems to be new
semantics for this header to me. I'm not sure that it is right to
replace the original Sender: field containing, say, the secretary's
mailbox with something that the email forwarder creates.
We have already established that a significant number of mailing lists
(20% +/- ???) do not supply a Sender: header. I don't think anyone
has check to see how many of the Sender: headers that are supplied
would likely be consistent with MARID validation.
I don't think any mail forwarders supply a Sender: header.
But, there is another class of problems with validating the Sender:
header with MARID, namely, what about the Sender: headers that are
already being generated? Looking through my inbox, I see quite a few
Sender: headers with either just the local-part of a mailbox or a
mailbox with an unqualified domain name. Like the mailing Sender:
headers, I haven't check to see how many of them would likely pass
MARID validation.
To the best of my knowledge, the Sender: header has never been widely
used in such a way that invalid headers would cause problems. In this
sense, they are similar to the HELO domains.
2822 From If Sender is not present then there is no reason this should
not be consistent.
I can't think of any problems with RFCs here, but I haven't pondered
things like multiple mailboxes on the From: header and the
relationship with the Sender: header and such.
-wayne