-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the end of January Dave Crocker posted a review of the then current "-01" version of draft-gondwana-dkim2-motivation. This document has now been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over 14 (sorry) emails... ">>" is a quote from our document, ">" a quote from Dave Crocker ... lines that do not start with a ">" are me speaking. - -=-=-=-=-=-=-=-=-=-=-=-=- >> 4.4. Simplifying error handling for intermediaries >> >> *Issue:* >> >> ESPs and other entities that send email on behalf of others have a >> need to know when delivery errors occur. > >An ESP and other senders 'on behalf of' are not 'intermediary'. They are >agents >of the author. Hence any issues for them are internal to the author's >organization. > >Also, having them generate mail that has them, or their customer as recipients >of bounce message is a matter of their choice. > >> At present this can only be >> done by changing the RFC5321 return path so that DSNs will be >> delivered to an intermediary rather than original sender. > >In what way is this a problem? > >> Non- >> standardised mechanisms such as VERP or SRS may be employed to be >> able to pin down the details of the failure. > >Since they are originating the message, they are not 'changing' the SMTP Mail >From. They are simply creating it, using their own address. There is nothing >in email that makes this an issue, except for linking SPF and DMARC. > >As for 'pinning down the details of the failure', what does that mean? For one example, when DSNs are generated they may not contain sufficient information about the email to permit the relevant recipient to be identified in the ESP's records >> *Mitigation:* >> >> In DKIM2 DSNs are passed back along the outgoing path so the ESP will >> receive the DSN and, depending on contractual arrangements, may be >> able to avoid passing this message any further back along the chain. > >This is relying on the complex return handling path when it isn't needed. The ESPs and mailbox providers we have talked with are enthusiastic. >> *Issue:* >> >> A mailing list wishes to learn when email it has handled cannot be >> delivered. At present DSNs (as opposed to next hop delivery >> rejections) are often passed to the originator of the email (the >> value in the [RFC5321] MAIL FROM) and are invisible to the mailing >> list. >> >> *Mitigation:* >> >> Passing bounces back along the outgoing path allows a mailing list to >> take responsibility for the event and not bother the person who sent >> a message to the list. > >Solving a non-problem. > >A mailing list is generating a new message posting. It can choose the SMTP >Mail >From to be anything it wants, including itself, and this is common. So this >is >not a problem and does not require additional mechanism. We will have to differ there. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ/l1JmHfC/FfW545EQJgEwCdHqXymXQK+73iKnjRyaPHTUvLuJQAn3zF 5vdKcvDSa+YJi6RL54WlExgJ =t0DR -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
