On Tue 29/May/2012 15:15:54 +0200 Tony Finch wrote:
Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
Second, for XXX, I'd suggest updating RFC 5451 and extend it as
appropriate. A question is that the client-added header field should be
signed in order to be considered reliable.
I'll have a look at that. What I had in mind was a Transmitted: trace
header that parallels the Received: header, and some new "with protocol"
types (e.g. esmtpt) to assert that the client had done some extra
checking. But this would add a lot of bloat for one bit of information so
perhaps it should just be left in the logs. Dunno.
In January, I proposed a similar field (Sent:) for tracking delays,
and Ned's comment is here:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04126.html
For a bloated debugging functionality, you could also try something
like dmarc or dkim-reporting...
Regarding authenticity of the header, I could say that any DKIM
signature should be added after the Transmitted: header. But then you'd
have to generate different signatures for each transmission of a message
which is not currently the case.
But I'm not sure what a server can meaningfully do with knowledge of how
much checking an unauthenticated client claimed to perform. At the moment
I'm just thinking of this trace information existing for debugging
purposes and for deployment tracking and suchlike, so there's no need to
be particularly precious about it.
IMHO, all of the "auth" techniques (SPF, DKIM, ...) are more or less
in a debugging state, as they are not mandatory and there's no clear
indication of how to use their results. This bit would add to that
sequence the knowledge that the sender considers that MX server
authoritative.
I'd guess that devising an SMTP extension whereby the client can
transmit some token that substantiates its claim is not quite what
you're after, is it? But there don't seem to be many other means by
which a publisher of TLSA records can learn whether anybody uses them.
Unless I'm missing something, the only places where that info is going
to be relevant is if the server rejects the message, if positive DSN was
requested but the server doesn't support it, and if the sending fails
because some of the specified checks failed. In those cases, the client
can prepare a bounce where the authentication results are reported in
detail.
Hmm, yes, I should add something about DSNs. Thanks. I think it might be
sufficient to register a new MTA-name-type, perhaps "dane".
(So regarding Ned's comment about the need for a general mechanism, I
think RFC 3464 is, happily, already sufficiently general.)
Indeed, that checking is relevant for DSNs. However, it would be
overkill to add an extra NOTIFY keyword, e.g. "DANE", for ensuring
that a report with "Remote-MTA: dane; something" will always be issued.