Re: [dmarc-ietf] Sender vs From Addresses
On Thu, Mar 25, 2021 at 5:53 PM John R Levine wrote: > >>> 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 > > I know people at Yahoo, and their filtering is largely based on complaint > statistics. If they're blocking your mail, the recipients are marking a > lot of it as junk. What do you see in the feedback reports? > > > 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. > > It's real simple. Delegate a subdomain or provide a signing key to a 3rd > party. In my previous incarnation we managed 6,000+ domains and both > Ironport and Message Systems allowed us to DKIM sign on the fly for any of > the our own domains at our border MTAs. Earlier on we were able to do the > same with a little more effort with well known open source mail servers. If > service providers aren't willing or able to work with either delegated > subdomains or delegated DKIM keys, shame on them. That is a business > problem on their part, not an interoperability problem. I am slightly more > sympathetic in the case of mailing lists which is a different problem space. > > I explained the downside to Sender a few messages back: it lets people put > any address they want in the From line so it becomes just a filter on the > reputation of the DKIM or SPF domain. If that were adequate, they > wouldn't have invented DMARC. > This was the problem with *Sender ID* and PRA. Back in the day I used to taunt the folks at Microsoft (Craig and Harry) by sending them email with their own From address by leveraging the Sender address and PRA to game a *Sender ID* neutral. It frustrated the hell out of them. As has been pointed out many times, there is no way of determining if Sender domain has any relationship to From domain unless it is in the same administrative domain. > > I agree that there is no particular downside to something like ATPS, but > the fact that we've had ATPS for a decade and nobody has implemented it > tells me that this is not a problem that the industry thinks is worth > solving. > +1 > Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
On 3/25/2021 2:23 PM, John R Levine wrote: While I am not opposed to a future tweak to DMARC to add some way to say that A can sign for B, even if we did it, it would be a long time if ever that DMARC verifiers implement it. RFC 6541 added a third-party signature option to DKIM in 2012, and after nine years, nobody implements it. Wildcat! SMTP implements RFC6541 "Authorized Third Party Signature" (ATPS)/ I'm sure I am not the only one and/or others have the options to enable it. There are wizard for ADSP+ATPS and DMARC+ATPS: https://secure.winserver.com/public/wcADSP https://secure.winserver.com/public/wcDMARC It works in proving the assertion by a 1st party Author Domain authorization for the existence of a specific 3rd party signer domain signature. Results are stamped in "Authorization-Results" header. Add "atps=1" to your DMARC record and create a ATPS record to authorize 3rd party signature domains. These domains are authorized to resign mail for the domain isdg.net jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) lykm653kj7yxeia665va7lszzthcx7jj._atps TXT ( "v=atps01; d=beta.winserver.com;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" ) It can be managed like any other system. This allows receivers to support a MAILING LIST that has resigned mail - the key problem we had since ADSP and now since DMARC because DMARC never bothered to even address the main concern with ADSP - the lack of a method to authorized a 3rd party. ATPS offers it. As to why the IETF.ORG mailing list does not support it or explore it and has chosen instead to rewrite, I don't know, but its so simple --- a DNS Lookup without any 5322.From tampering. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
" I explained the downside to Sender a few messages back: it lets people put any address they want in the From line so it becomes just a filter on the reputation of the DKIM or SPF domain. If that were adequate, they wouldn't have invented DMARC." Not using the 'authorization of specific domains through DNS' solution which is clearly the more thorough of the two I mentioned. Charles A. Gregory CEO Possumdelight Technologies char...@possumdelight.com (678) 778-7200 "If it's time sensitive, e-mail AND call." - Charles Gregory -Original Message- From: John R Levine Sent: Thursday, March 25, 2021 5:53 PM To: Charles Gregory ; Gren Elliot ; dmarc@ietf.org Subject: RE: [dmarc-ietf] Sender vs From Addresses >>> 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 I know people at Yahoo, and their filtering is largely based on complaint statistics. If they're blocking your mail, the recipients are marking a lot of it as junk. What do you see in the feedback reports? > 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. I explained the downside to Sender a few messages back: it lets people put any address they want in the From line so it becomes just a filter on the reputation of the DKIM or SPF domain. If that were adequate, they wouldn't have invented DMARC. I agree that there is no particular downside to something like ATPS, but the fact that we've had ATPS for a decade and nobody has implemented it tells me that this is not a problem that the industry thinks is worth solving. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
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 I know people at Yahoo, and their filtering is largely based on complaint statistics. If they're blocking your mail, the recipients are marking a lot of it as junk. What do you see in the feedback reports? 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. I explained the downside to Sender a few messages back: it lets people put any address they want in the From line so it becomes just a filter on the reputation of the DKIM or SPF domain. If that were adequate, they wouldn't have invented DMARC. I agree that there is no particular downside to something like ATPS, but the fact that we've had ATPS for a decade and nobody has implemented it tells me that this is not a problem that the industry thinks is worth solving. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
>> 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, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please >consider the environment before reading this e-mail. https://jl.ly Best, Charles Gregory ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
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? 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. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
"It sounds like they're asking DMARC to do things it doesn't do. If you can't ensure that everything sent with your domain on the From line is signed with your signature, you shouldn't publish a DMARC policy." 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. "If your user's Sender and From domains belong to the same owner, it should be a SMOP to add a signature in the From domain." Believe me, the corporate red tape of a multinational corporation is not a SMOP. Consider how this SHOULD work with email service providers to a small business. Emails should appear FROM CompanyA while the SENDER appears FROM MailChimp. These are legitimately separate concerns. Bounces go back to MailChimp for processing. The receiver sees CompanyA in the from field. DMARC threw the baby out with the bathwater. If you want to eliminate spoofing and cut down on SPAM/Phishing/Scams without crippling SMTP and all the collateral damage, a domain should have the ability to authorize other domains to send mail on their behalf. Any "unauthorized" domains would fail DMARC. CompanyA specifies mailchimp.com as an authorized sending domain. SPF verifies the sending email server IP address is authorized to send on behalf of mailchimp.com. "I'm not saying it's trivial, but this is how DMARC works." 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. "The rest of the world will not change the way it works to adapt to your situation rather than you fixing your setup to work with DMARC as it exists." Maybe; but I am not alone on this. The way DMARC disregards the Sender address has unintended consequences that negatively affected countless companies and applications - and reduces the functionality of SMTP. I would like to think that things could be improved. Then again, it really seems like it's time to go back to the drawing board and start over... SMTP 2.0??? Best, Charles A. Gregory CEO Possumdelight Technologies char...@possumdelight.com (678) 778-7200 “If it’s time sensitive, e-mail AND call.” - Charles Gregory -Original Message- From: dmarc On Behalf Of John R Levine Sent: Thursday, March 25, 2021 2:24 PM To: Gren Elliot ; Kurt Andersen (b) ; dmarc@ietf.org Subject: Re: [dmarc-ietf] Sender vs From Addresses > Calconnect’s TC-CALSPAM group is currently looking at this issue and > yes, the reason is because of real world corporations that use > multiple brands with different domains. Typically employees got a > single email address on one of their domains but often work with > people who have email addresses in different domains. Oh, OK. "It sounds like they're asking DMARC to do things it doesn't do. If you can't ensure that everything sent with your domain on the From line is signed with your signature, you shouldn't publish a DMARC policy." It is a problem when receiving servers use DMARC existence and pass/fail to increase/decrease deliverability rates. While I am not opposed to a future tweak to DMARC to add some way to say that A can sign for B, even if we did it, it would be a long time if ever that DMARC verifiers implement it. RFC 6541 added a third-party signature option to DKIM in 2012, and after nine years, nobody implements it. This is not the same problem as we have with mailing lists. If your user's Sender and From domains belong to the same owner, it should be a SMOP to add a signature in the From domain. I'm not saying it's trivial, but this is how DMARC works. The rest of the world will not change the way it works to adapt to your situtation rather than you fixing your setup to work with DMARC as it exists. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
Calconnect’s TC-CALSPAM group is currently looking at this issue and yes, the reason is because of real world corporations that use multiple brands with different domains. Typically employees got a single email address on one of their domains but often work with people who have email addresses in different domains. Oh, OK. It sounds like they're asking DMARC to do things it doesn't do. If you can't ensure that everything sent with your domain on the From line is signed with your signature, you shouldn't publish a DMARC policy. While I am not opposed to a future tweak to DMARC to add some way to say that A can sign for B, even if we did it, it would be a long time if ever that DMARC verifiers implement it. RFC 6541 added a third-party signature option to DKIM in 2012, and after nine years, nobody implements it. This is not the same problem as we have with mailing lists. If your user's Sender and From domains belong to the same owner, it should be a SMOP to add a signature in the From domain. I'm not saying it's trivial, but this is how DMARC works. The rest of the world will not change the way it works to adapt to your situtation rather than you fixing your setup to work with DMARC as it exists. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
