I have not seen an identity problem with ESPs, bevause messages are received directly. They consistently use their own domain for MailFrom to ensure SPF pass, and the client domain for From. Domains that use DMARC enforcement have signatures.
Additionally, the From domain correctly presents the client identity, so I do not fear spoofing, even from ESPs that happily provide their services to criminal domains. Those that serve criminals have all of their unclassified clients sent to administrative quarantine. A small portion that is found to be wanted traffic will be released and exempted from quarantine on future messages. If the same messages were received indirectly, it would be a problem because the SMTP rewrite hides the ESP identity, so the quarantine would not happen. Hence, I must start scanning the entire Received chain and related headers. Since everyone deals with the same ESPs, I think everyone needs to do full scans also. DF On Mon, Jan 4, 2021, 2:24 PM Alessandro Vesely <ves...@tana.it> wrote: > On Mon 04/Jan/2021 13:22:20 +0100 Laura Atkins wrote: > >> On 4 Jan 2021, at 11:50, Alessandro Vesely <ves...@tana.it> wrote: > >> > >>> Lets define "legitimate mail" as used in my proposed text to mean > "delivery > >>> is desired by the intended recipient and the message contains nothing > that > >>> threatens the interest of the user, the interest of the user's > network, or > >>> the policies of the user's organization." Perhaps this is too > >>> restrictive, because it excludes advertising which is harmless in its > >>> intent but unwanted by the recipient. > >> > >> Having advertisements come /From: advertiser/ is a goal. > > > > Yes. > > > > [snip] > > > >>> Email evaluation products need to handle all possible scenarios. This > >>> includes > >>> - forwarded and not forwarded > >>> - with and without SMTP rewrite > >>> - with and without modification. > >>> - with and without From rewrite > >>> - with and without ARC sets > >>> - whether the email header chain is accurately documented or > fraudulently fabricated. > >> > >> Girl Scout troops will inevitably fall in the not forwarded category. > ESP messages, instead, should come /From: ESP/. > > > > This incompatible with the above goal of having advertisements come from > the advertiser. > > > That depends on how you define "advertiser". If you entrust your > communication to an external agent, the advertiser becomes that. Maybe, an > agent they could differentiate by using subdomains, similar to the " > onmicrosoft.com" suffix. > > > > I find it highly problematic that we’re teaching recipients that they > get official mail from companies that come from an address that is not > connected to the company at all. It further devalues the 5322.from and > means that recipients cannot trust the domains that the see there. This is > even more true when the domain is one they’ve never heard of and passes all > of the checks and comes in with a ‘verified by DMARC.’ > > > Agreed. > > A recipient should somehow trust the ESP, or else discard their messages. > > Then, there are several ways that an ESP (or a MLM) can try and convey > some kind of transparency of intents. One can use subdomains and display > names. IMHO, we should add some guidelines about this in the spec. > > Of course, publishing the ESP's selectors would complete the entrust > better. The scalability looks similar to that of subscribed feedback loops. > > (Managing communication internally is even better.) > > > > There is absolutely nothing stopping a phisher from taking advantage of > this. In fact, phishers currently do send DMARC verified email where the > domain in the 5322.from is unrelated to the links in the message or to the > domain being phished. > > > We cannot prevent phishers from doing so anyway. Yet, if we insist on > using DMARC nevertheless, authentication will create "a noise-free basis > for developing an indentifier's reputation", in Dave's words. > > > > This seems to me to be a step along the path of making DMARC irrelevant > by teaching recipients that mail with a 5322.from address they don’t > recognize is legitimate email. > > > It is as legitimate as the identifier's reputation. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
