Vlatko Salaj writes: > 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. This is a big hurt *all by itself*, and so worth a whole protocol to reduce it. The reason is that even with a low "conversion rate" on the phishing message, individual customers can be hurt very badly, and the profits are big enough that there's strong incentive to engage in email fraud for this purpose alone. You have a different use case, you need a different protocol. > what's the point of DMARC then? Building safer email, one brick at a time. You need a different brick. Why delay DMARC implementation because your brick isn't baked yet? > ppl r arguing against strong DMARC settings cause they r broken, But they're not broken when used in a "direct mail" context. The "on behalf of" use cases and the "mailing list" use case are a harder problem. Standardizing DMARC (in or out of the IETF process) is a case of "don't let the best be the enemy of the good." > 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. Many proposals have been made, but they all failed because some party essential to the success of the protocol would refuse to cooperate. :-( _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
