On Monday, April 21, 2014 11:32 PM, Hector Santos <[email protected]> wrote:
>>> This would be a simple first step consideration -- A new ATPS tag >> this may fix DKIM 3rd party support, but does little to support >> 3rd party SPF. i think it's important to have a fix for all >> underlying mechanisms, not just some of them. > How do you define a 3rd party SPF condition that isn't already defined > and authorized by the 1st party? IOW, by virtue of the 1st party > adding the 3rd party information into a SPF record, it is inherently > ready for 3rd party operations. No? no. 3rd party SPF support in DMARC's alignment context means support for 3rd party SMTP MAIL FROM, or 3rd party HELO/EHLO. by SPF specs, there are no provisions for 3rd party SPF support in this sense. what SPF specs do allow is adding 3rd party servers to the IP pool of senders, but that's not full 3rd party support actually, in DMARC alignment terms. > If DMARC is about conforming to DKIM operations, then it SHOULD of > provided the option for 3rd party signers to exist. i agree on this fully. it's only the question of how... and i would rather see it inside DMARC, instead of outside of it. > My thinking was that DMARC was never really meant to be a policy > handling protocol but a reporting protocol. this does make sense, especially how badly alignment requirement was imagined. however, since it's more than a reporting protocol now, and it's a promising one, we should fix it to include 3rd party properly, as it should have been done in the 1st place. > Unfortunately, they really didn't do a good job in satisfying > all the possible boundary conditions of the DKIM+POLICY+TRUST model. > In other words, they didn't really learn, did they? DMARC is very > limited and that is what the IETF has to address. +1! -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
