On Fri, Jun 6, 2014 at 7:09 AM, Vlatko Salaj <[email protected]> wrote:
> just like FCC's recent corrupted moves to promote what was almost > unimaginable a few years back, which, even if successful, will be > dismissed sooner than later, and whole fiasco will be looked as a dark > history of internet, DMARC support will be left out by worldwide > developers, cause it's a complete waste of their time and energy, and > doesn't serve high goals it proclaims it does. > The current deployed base of DMARC appears to disagree. Setting aside Yahoo! and AOL (the controversial cases), there are several operators who have been using DMARC for quite some time now that don't cause problems and they have enjoyed huge benefit from it. > i will repeat myself: nobody will develop a support for a lousy > protocol that has a high probability of breaking delivery of a > perfectly legitimate email, while trashing everything developed for > email last 20y or more: mailing lists, forwarding, send2friend, and > whatever 3rd party email processing someone imagine useful to them. > Reality appears to differ. PayPal, Bank of America, and Facebook at least have been using it for a long time, and I'd bet you didn't even notice. > why? cause u failed to develop a protocol useful to all parties. > > so all that energy and work will go to waste, when IETF puts > "historic" on DMARC standard, and moves on to some better place. > I have to assume you're referring to ADSP here, which was recently marked "Historic". However, DMARC has already enjoyed more adoption than ADSP ever did, even with its controversy. I think I know some of the reasons why, and we can go into them if you like. > > Standardizing DMARC (in or out of the IETF process) is a > > case of "don't let the best be the enemy of the good." > > i would rather say it's a case of "history repeating". how many > email policy protocols were developed in last 10y? a bunch of them. > all of them failed. all of them "historic" now. > Which ones, other than ADSP? > it's beyond obvious DMARC needs a 3rd party support. every email > standard has it: SPF has it, DKIM has bunch of them, ESPs have them, > websites have them... name any email thing that works on wide scale > and take a few seconds to realize what's its 3rd party support > in its basic functions. > Although SPF and DKIM do have third party delegation tools (in DKIM's case, at least two), they have never had much uptake. Perhaps that will change as DMARC continues to evolve, but so far the industry as a whole (not the IETF) has not found their use to have more benefit than risk. > actually, AFAICS, we have three complete solutions for 3rd party support, > and that's counting last few months, not from the beginning of DMARC > development, which may have produced many different solutions; and i > don't doubt it did, cause problems r obvious and real. > To answer Stephen's question, I'm guessing you're referring to ATPS (RFC 6541), use of CNAME to point to an externally-posted key, and a key exchange where an operator give a third party a signing key. If there are others, I'd like to know what they are. All three would require the Yahoo!s and AOLs of the world to grant signing keys, signing key aliases, or ATPS records to every domain that might re-send their mail. There are some obvious issues with such solutions: (a) users will have to register every list to which they subscribe and wish to post; (b) they will have to automate DNS updates because every new entry into that registry will require a new DNS entry; and (c) if any of those third parties gets compromised, it's a big problem for the domain trying to protect itself. If any bit of this fails (and I suspect (a) is actually the bigger problem), they don't work. the real problem with 3rd party support for DMARC r DMARC "gate-keepers". > they r like FCC now, listening to small minds from big towers, reluctant > to make "a small step as a jump for email kind". > I don't think that's a fair characterization. I think the more likely explanation is that the proposals on the table are much too risky and costly given the benefits. If a better one comes along, I'm sure it would be considered. > > having it at IETF as an informational RFC speaks volumes on its fate. > if it was actually beneficial to internet, it would go most common and > regular IETF standards track. > > The status of the current document has nothing at all to do with the quality of what's in it, but rather the procedural path it's taking toward publication. On the Independent Submission track, the only status available is Informational. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
