I predict "fun time" running this "stripping" by ietf-smtp and ietf-822
folks (especialy as Authentication-Results is defined similar to trace
fields)...
Bring it on. I'm always ready for "fun time".
ReturnPath is supposed to be MDA-added header field and there supposed to
be only one MDA that delivered email. That means that for email that is
subject to normal delivery on the internet, there should be no ReturnPath
header field and its only ok for LMTP or for POP3/IMAP email retrieval
RFC 2821 section 4.4 states this:
--8<--
It is sometimes difficult for an SMTP server to determine whether or
not it is making final delivery since forwarding or other operations
may occur after the message is accepted for delivery. Consequently,
any further (forwarding, gateway, or relay) systems MAY remove the
return path and rebuild the MAIL command as needed to ensure that
exactly one such line appears in a delivered message.
--8<--
It goes on to further discourse on the Return-Path header and the stripping
thereof. If any of this is done to a message that was signed and who's
signature includes said Return-Path you get a broken signature as a result.
Therefore, since the specifics of the Return-Path header provide
documentation whereby it is reasonable to assume that it could be stripped
we should recommend against it's inclusion in the signature calculation.
This is not the same for Authentication-Results as for debugging I would
find it useful to have Authentication-Results header field present which
was added by another server in email path (I would not trust it, but that
is another matter).
The AR specification states under what criteria the header would be stripped
and your use case above is not part of that criteria. No AR header must be
stripped which was added by another server. But consider this case (which
happened to me personally during DKIM development). It's a little
complicated but this will be a common setup:
Server A is my border MTA. All mail from the Internet comes to A. Server A
checks Anti-Virus/Anti-Spam, SPF and DK/DKIM and adds an AR header properly
citing itself as the host who performed the checks. Server A then forwards
clean incoming mail to server B. Server B hosts mailing lists and local
mailboxes. A message which came in from Server A to Server B discovers that
the message is to a mailing list or a local user who is forwarding a message
elsewhere. Server B explodes the list message or generates the forwarded
message, signs it with DKIM (because it signs all messages), and finally
sends the resultant signed email to Server A for Internet delivery. Now,
when Server B signed the message which has already been processed by Server
A it signed it with the AR header which Server A previously added. Server B
does not equal Server A so there is no requirement to strip AR headers added
by Server A. Now, when Server B sends the message to Server A for Internet
delivery, Server A follows the AR specification and removes the AR header
which it previously added. This act invalidates any signature which
included that AR header in the signature calculation. Again, the AR spec
states (and it's correct) that for security reasons, a host must remove any
AR header which cites itself as the source.
There are only three ways to deal with this problem that I can see: (a)
setup a software trust system between Server A and Server B such that Server
B will not need to strip AR headers from messages which are sent to it from
Server A (b) change your email topology so that mail is only signed by the
outermost border MTA or (c) don't sign headers that, by their own
specification, are subject to munging, changing, removing, stripping,
<insert favorite change mechanism here>. It's easiest to specify (c)
because (a) requires special MTA code to handle trusts between servers in
the limited context of the handling of a single mail header which seems sort
of silly and (b) requires companies to completely change their network
layout and mail routing practices (not practical in the least IMO).
We can punt this and a thousands other currently unknown weird signature
breaking issues with the simple statement "don't sign headers likely to be
changed, removed, replaced etc because if you do, you just hosed the
system.".
How do you deal with Sender? How about From, Reply-To, To?
Is there special RFC text somewhere stating conditions under which these
headers must be stripped from emails?
--
Arvel