[Top] [All Lists]

Re: [mail-vet-discuss] Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard

2008-11-24 13:40:31
On Mon, Nov 24, 2008 at 09:24:15AM -0800, Dave CROCKER wrote:

I wanted to raise another issue. Should there be any discussion of the
semantics of "Authentication-Result" for message/rfc822 attachments
(nested messages). Clearly such headers cannot be assumed to be filtered
at the MTA layer and should be presumed untrusted.

I think you are trying to carry the semantics of the authentication that this 
covers too far.  For example, I believe this mechanism is not intended for 
personal or fine-grained authentication, as done by OpenPGP or S/Mime. One 
imagine extending it, but

Whether the body -- in its entirety -- is authenticated explicitly depends 
the semantics of the particular authentication technique.  The specification 
provides for some parameters that might be used to this end, but the details 
this way is not in this initial specification, nor should it be, in my 

The specification's primary goal is to pass a single, overall results value. 
Everything after that is far more subtle than needed for its initial use.

Oops, perhaps I did not make my point sufficiently unambiguous:

            Authentication-Result:; spf=pass
            From: <A(_at_)example(_dot_)com>
            To: <B(_at_)example(_dot_)net>
            Message-Id: <C(_at_)example(_dot_)com>
            Subject: mumble
            Content-Type: multipart/mixed; boundary=b

            Content-Type: text/plain

            See attached message

            Content-Type: message/rfc822

 ===>>>>    Authentication-Result:; spf=pass
            From: DA(_at_)example(_dot_)com>
            To: <E(_at_)example(_dot_)net>
            Message-Id: <F(_at_)example(_dot_)com>
            Subject: mumble2

            This is the attached message


What is the meaning of the NESTED "Authentication-Result" header? It
can't be trusted, and should not be trusted when the nested message
is "extracted" from the containing message...

I suspect you are looking more for 
some sort of broader 'best practices' document about the ways authentication 
information passed to an MUA should be used.  It will probably be best to 
until there are some real-world practices, before deciding which are best...

No, I think this is a "Security Considerations" issue, not a
best-practices issue. I also think that if we discover that such a header
cannot be made reasonably forgery proof (too many ways to bypass forgery
filters) we should consider whether the header should be standardized...

I'd very much *like* to have a usable standard in this space, but it
needs to be reasonably robust, and if (perhaps) that is not possible,
I'll settle for "no standard" rather than a weak standard.

What the MUA does with a message and with meta-information about the
message is far outside the scope of this specification.

The standard is created for MUAs to consume, we need to consider real
world MUA use cases, to understand whether the standard holds up to real
world threats.

I am not entirely optimistic that MUAs will solve this problem.

Well, ok, one might therefore justify a doctoral thesis...

What is the point of this specification? Is it primarily for the benefit
of MUAs, or primarily for downstream MTAs and junk-mail filters?

If it is for MUAs, why are considerations of issues MUAs will face in
using the specification out of scope? If MUA issues are not tractable,
refocusing on mid-stream infrastructure may be more appropriate.

Once the standard is published, MUA developers may begin to implement
it without due consideration of all the issues.

It may, for example, be more appropriate for the header to be consumed
only by the mailstore (or MDA) and messages in the inbox flagged as
trusted by a separate store-specific mechanism. This would address the
"old message" issue, detaching of attached messages, ...

Sure, none of these trust/security issues change the format, but the
format lives in the context of implied use-cases, which should I think
be reasonably well understood.

NOTE WELL: This list operates according to 

<Prev in Thread] Current Thread [Next in Thread>