On Monday, April 14, 2014 9:59 AM, Murray S. Kucherawy wrote:

>> come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but
>> in very narrow field.
> Do you have any specific suggestions 

as a matter of fact, yes, i do.

i already mentioned including SRS in check logic. unfortunately, no dmarc
author rly added much to the topic, and i work alone only on my own projects,
not on collaborative things as these.

also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st, would be:
a. dmarc alignment is a big issue. read: huge issue.
b. since alignment is an issue, make it policy optional.
c. by "make it policy optional" i mean: include an option in dmarc dns policy,
so that domain owners could turn dmarc alignment check on/off.

this could be useful for:
domains using high volume ML participation,
domains that use 3rd party services for their email infrastructure,
domains that use forwarders,
bunch of other special cases u can find on internet today and in future.

my 3rd suggestion, which would go nicely together with 2nd, is:
1. current dmarc spec uses OR logic while processing SPF and DKIM; why?

2. make this policy processing logic selectable.
3. by "make it selectable" i mean: include an option in dmarc dns policy,
so that domain owners could turn dmarc processing logic either to OR or AND.


my 2nd and 3rd suggestion, in combo, would deal much better with stuff
that, originally, dmarc spec had OR processing logic meant for, and while
doing that, it would also add so much needed wideness to dmarc rigidity.


and i could even pass dmarc finally. imagine that. while still getting some
benefit from dmarc processing.


is there a weakness in this proposal. probably. is it huge. i don't think so.
u disagree? elaborate, plz.



-- 
Vlatko Salaj aka goodone
http://goodone.tk

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to