On Fri 25/Jul/2014 21:46:10 +0200 Dave Crocker wrote:
On 7/25/2014 2:41 PM, Tony Hansen wrote:
However, subsequent work with DKIM showed that i= was unreliable for
that purpose, and instead should be treated as an opaque value.
Not just unreliable; the spec really wasn't document to that use.
Yes.
If I were to change the text in any fashion, it would be to change the
words "provide ways to ascertain" to something like "provide tools that
could help ascertain".
Uh, no. The semantics of SPF and DKIM don't really do that. Any use in
that direction goes far, far outside of the specs.
That can be understood as a request for a next-layer spec. Consider
some kind of machine-readable statement by a DKIM signer or SPF domain
owner, such that an MTA can quickly decide whether it's worth to send
a (positive or negative) DSN to an address in a foreign domain, based
on it.
To avoid backscatter, some MTAs skip sending DSNs unless they refer to
submissions --that is, they are bound for internal users. Some other
MTA send bounces, and when I receive one I'm often tempted to ask them
why they sent it. We need a statement that could be cited in the
footer of the readable part of a DSN, explaining why it's worth to
send such stuff to such kind of address in the given circumstances.
Ale
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp