-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Arvel
Hathcock
Sent: Tuesday, July 19, 2005 4:31 PM
To: ietf-mailsig(_at_)imc(_dot_)org
Subject: Re: DKIM - Header Fields
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