>> We don't see any way to tell these apart without consulting external
>> reputation databases, which are way outside the scope of ADSP and DKIM.
>
> OK, but I don't see how it helps to put the job of making this
> judgement on the implementor, who probably has less expertise
> and time to think about this than the DKIM WG has
Honest, we thought about it and have no advice to give. Different
mail users will have different tradeoffs between losing real mail and
accepting bogus mail, and we really have no experience at all with
signed mail with multi-address From: other than contrived examples.
As a practical matter the issue of how multiple From: fields are handled has
become largely moot, in my experience at least. The mail client I use is one
that supports generation of this construct, but the last half-dozen times I've
tried it something has gone wrong every time - the receiving client mishandled
it, the message was blocked by overly aggressive filters, etc. etc.
After the last times, when a message to an IETF list was silently dropped and
i was forced to ask one of the other recipients to resend it (having neglected
to keep a copy myself), I've given up on this construct, even though I find
it's semantics to be valuable.
As always, the plural of anecdote is not data, so there may be places I'm
unaware of where this construct is in use and doesn't cause any problems. But
given the mainstream nature of the various agents I've seen fail to handle
multivalued From: fields sensibly, my suspicion is there aren't very many such
places.
Now, I suppose an argument could be made that this points to the need for ADSP
to specify semantics for handling multivalued From: fields in order not to
break multivalued From: even more. But that argument only makes sense if we
believe that there's a single semantic we can assign that is broadly
applicable, and I don't think anyone believes that. And given a choice between
ADSP and not causing some additional breakage to a mostly broken minor
capability, I think the right choice is pretty clear.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf