Re: [dmarc-ietf] Sender vs From Addresses

[Charles Gregory <[e-mail]>]

>> It is a problem when receiving servers use DMARC existence and 
>> pass/fail to increase/decrease deliverability rates. - And when 
>> Yahoo/AOL pretty much block everything you send - even with a 98 
>> sender score, SPF, DKIM, and clean opt-in lists.

>Are they rejecting on DMARC failure because you're publishing p=reject? 

NO p=none

>If so, they're doing exactly what you're asking them to do.  If you don't want them to reject your mail, why are you telling them to do that?

>I realize that getting large organizations to act coherently is close to impossible, but that doesn't mean the rest of the world has to work around their failures.  If it's not important to them to make their DMARC records match their actual practices, it's not important to >anyone else, either.

>> Going back to the beginning, DMARC breaks how SMTP worked.  The Sender 
>> address serves a purpose.  This is the address bounces should return to.
>> DMARC took a steamroller to the Sender address and it didn't have to.

>Yes, we all know DMARC's problems.  I complained as loudly as anyone when AOL and Yahoo abused it to push the costs of their security failures onto everyone else.

>But the people who designed it knew a lot about the way that mail works, they they did what they did.  Prior attempts to key on sender were a complete failure.  I hope you have read RFC 4407.  You don't have to like the way that DMARC ignores Sender, but it's not an >accident, and telling people they are stupid is not going to change any minds.

I don't remember saying anything like that John.  I doubt anyone in this thread has a low IQ.  In fact, I am very thankful for this discussion and everyone who is taking part.  I am learning things from each of you outside of my general scope of operation.

I DO think this is an unnecessary problem that CAN be fixed/improved in one of two fairly straightforward manners through DNS (behavior switch or list authorized alternate domains).  And I can't see anything but upside in doing so; nobody has demonstrated a downside anyways.  Yet I have no idea how such decisions are made or the part that anyone plays here.  I will review RFC 4407.  Thanks.

>Regards,
>John Levine, [e-mail], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly


Best,

Charles Gregory