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
And that comment still stands. The issue is whether or not there's an
intended coupling of the field. Additional fields are acceptable, but not
when they overlap or interact with an existing field.
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.
None of them are mandatory to implement. But there's a lot of room between what
I'd consider debugging and what these things go.
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.
We already have that, more or less: The AUTH parameter on MAIL FROM. Of course
you have to authenticate for real before using it, which is how it should be.
But it isn't the appropriate tool to use in this case.
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.
Especially since that would have to be a separate extension, and then you run
into all the fun and games associated with the various cases where the
extension isn't present at some point.
ned