On Friday, June 6, 2014 2:56 PM, Stephen J. Turnbull <[email protected]> wrote:
>> i want to use whichever DMARC setting suits me, and >> to allow trusted 3rd parties to send email on my behalf. > AFAICS, DMARC was designed to deal with phishing for credentials via > fraudulent messages claiming to be from customer service of a large > large business entity. > You have a different use case, you need a different protocol. and how is my use case different? is it cause: 1. i don't have a phishing problem? 2. i'm not a big money entity? choose ur answer wisely, and beware how u thread. if ur answer is 1: u don't know that. and it's not ur business to know that. if i wish to protect my domain from phishing, it is my sole right to do so. it is also my sole right to do it the way i trust is sufficient for me. if ur answer is 2: building protocols that suit big tower corporations is just like net neutrality discussion we have now at FCC. 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. 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. if u rly want DMARC to succeed and have a wide scale support, u will do ur best to adapt it to internet at large. otherwise, u will be left with a half-baked protocol supported mostly by the same entities that developed it. and that's not whole internet. not even close. neither that solves ur phishing problems completely, as the rest of internet will ignore ur DMARC records completely and let ur phishing take place. 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. > Why delay DMARC implementation because your brick isn't baked yet? cause building houses while missing some bricks will surely result in their collapse at some point. and then u will have profit loses when ur reputation as a builder gets tarnished by angry customers obsessing with ur customer support. considering how many things DMARC doesn't support, that's actually a logical consequence. >> ppl r arguing against strong DMARC settings cause they r broken, > 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. why? cause they were unlucky enough to be half-baked. DMARC has a chance. will it use it? i'm quite sure it won't... why? cause, unless genius and creativity kicks in early in development process, things produced r usually mundane and mediocre. that's how DMARC feels now. but at least i'm giving my best not to let that happen. it must be that period of my life when a completely unknown individual openly and unconditionally contributes essential stuff to a future success. or i just care enough. whichever suits u to agree with me. 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. >> is using aidbands better than actually patching up the patient? > It is if you have a Band-Aid, but lack a sterile needle and thread to > properly suture the wound. We *don't have* a protocol for your use > case yet. 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. 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". > Many proposals have been made, but they all failed because > some party essential to the success of the protocol would refuse to > cooperate. :-( if DMARC doesn't assimilate some kind of 3rd party support soon, it will be a failure too. and i don't think it has much time left: 1 year probably, 2 years if u r rly pushing it. ppl already dismiss DMARC as a failure... and i don't blame them. 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. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
