On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed <ned.fr...@mrochek.com> wrote:
> > Actually same message to same destination may be > > sent to different MTAs (e.g. different MXs with same weight). > > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > > lowercase the domain of recipient. > > Our default is to leave the case of addresses alone by default, but sites > often > do configure things to "right case" their business name. That said, Early > validation would avoid such issues for us. I think. > Long ago some MTAs use to mess with the case of the domain names in the envelope. Assuming some of them are still out there, wouldn't we want to fold everything to lowercase (or uppercase; pick one) before doing the sort? > All problems except 2.1 may be fixed by adding additional header, like > e.g. > > DKIM-Transport-recipients > > which contains salted hashes (with some random salt) of all recipient > > addresses, and require this header to be added to DKIM signature and > > existence for every recipient's address' hash to be checked in this > > header. It is compatible with any current DKIM implementation. > > If you're talking about hashing all recipients together, then I don't see > this > solving all the problems except 2.1. > > And if you're talking about hashing them separately, then why would you > insist that they all be present? > I think he's trying to avoid being clobbered by an envelope that gets split downstream. If you as a verifier have the full original recipient set, then all you care about is that your recipient set is a subset of the original set. > But limiting the number of recipients to 1 when this extension is used > would be > a much simpler approach. Of course there's some overhead involved in doing > this, but given the idiotically limited spam report mechanisms in place at > some > sites single copy may be a requirement already. > It's also the most common use case in threat space, as I understand it. > Finally, my biggest concern here is that this, like most proposals that > involve complex linkages between the header and envelope, is complex > and loaded with pitfalls. (Just look at these two messages...) And at least > some of this spills over to both implementations and operational policy. > Indeed; I don't think that's avoidable if we want to try to tackle this problem versus punting it back up to layers 8 and 9. But maybe that's the best thing one can do. Can we really expect people to get this right? > I wonder that every time I write a draft anymore. :-) -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
