Vlatko Salaj writes: > > What I [== stephen] gather from Vlatko's posts is that there is a > > use case where an entity (eg, a small business; called "ENTITY" > > below) wants its own domain (called "OWNDOM" below) referenced in > > correspondence, but prefers not to maintain a single presence > > (even as a VPS) on the Internet. > > nope.
OK, so it's not. The solutions I propose still work if you have a physical presence but *choose* not to use it to send mail, and Franck Martin says that ESPs are open to cooperation as required by a subset of those solutions. The only difference is that there *may* be issues of spoofing or losing mail that happens to be delivered directly from your personal MTA. I didn't want to make the effort to be *sure* so I chose a setting where it wasn't an issue. > i want DMARC to upgrade itself to be able to respect that. Please stop writing things like that. It's either a semantic null or a troll. Somebody has to do the work, RFCs don't write themselves. If you can't write a whole draft, at least write an outline of the parts of the protocol your idea requires. > http://www.ietf.org/mail-archive/web/dmarc/current/msg00813.html Now that's more like it! Unfortunately there's no protocol in there, you leave it implicit. :-( And you must have some new (undefined) forms of "alignment", as mail "From: [email protected]" can never satisfy DMARC identity alignment with yahoo.com credentials. Eg, what is being aligned" in (2)? Your "example" isn't a conforming DMARC record, in fact it even usurps existing protocol (that's a no-no, even if a spec is only at draft stage; it's not that hard to choose a new name, and adjust nomenclature whan publishing a new draft). Finally, the post is full of minor inaccuracies, like writing "Sender-ID instead of SPF" when Sender-ID depends on SPF. Unfortunately, AFAICS it doesn't address my needs (ie, MLMs), so I doubt I will be able to find time to work through it and figure out what you're suggesting in concrete terms. > also, it's easier than VBR, ATPS, TPA, TPA-Label, and moves > trouble of authorizing legitimate email from receivers' > error-prone, DMARC-policy-disrespecting, essential > whitelisting to domain-owner's control, where it should be. I disagree with "where it should be". The receiver has ultimate say on what messages it will accept, whether for relay to third parties or local delivery (or even "silent discard"). > what u r proposing, Stephen, instead, is not at all trivial or easy > to implement, Huh? Define "trivial" and "easy." Technically speaking, AFAICS DKIM signing in the MUA is a SMOP (and in fact it can easily be done outside of the MUA but on the same host as the MUA by a separate application), many users with a personal domain can handle setting DMARC and DKIM resources, and I see no reason why ESPs would alter the signed portion of a message. If the user *can't* handle setting those resources or your preferred ESP insists on corrupting your messages, asking the ESP to handle all of SPF, DKIM, and DMARC for mail purporting to be from your domain is an obvious solution, and if the ESP goes rogue or has a security breach compromising your private keys, you delete the authorizing resources from your DNS. > nor does it solve more than just my special use case. So what? It's easy to implement and solves a use case that must be fairly common out there. Get real, man -- you're bitching *because* it solves your use case?! _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
