No. It's how DMARC uses SPF. Scott K
On November 22, 2019 11:25:47 AM UTC, Wesley Peng <wes...@thepeng.eu> wrote: >Would this list break SPF then? Thanks > >On Fri, Nov 22, 2019, at 7:15 PM, Richard Damon wrote: >> On 11/21/19 11:47 PM, Wesley Peng wrote: >> > Richard Damon wrote: >> >> That is a question to ask them. Basically the strict DMARC policy >is >> >> designed for transactional email, where spoofing is a real danger. >The >> >> side effect of it is that addresses on such a domain really >shouldn't be >> >> used on mailing lists, or any other 3rd party senders not >specifically >> >> set up for that by the domain owner. For the proper usages of >this, it >> >> really isn't much of a problem, as the sorts of institutions that >deal >> >> with this sort of transactional mail, probably shouldn't be using >that >> >> same domain for less formal usages that tends to go with a mailing >list. >> >> >> >> The problems arise when a domain that doesn't really need that >level of >> >> protection adopts it for some reason, especially if they don't >inform >> >> their users of the implications of that decision. >> > >> > Hello Richard, >> > >> > If I am wrong, please forgive me. >> > >> > Many ISP/Registrars provide email forwarding, I even had a >pobox.com >> > account which I used for 10+ years with just forwarding feature. >> > >> > When a mail like mail.ru was relayed by those providers, it sounds >> > easy to break SPF/DKIM, so the recepients may reject the message. >This >> > is not good practice for the sender, even for mail.ru itself. >> > >> > Am I right? >> > >> > regards. >> > >> Normal forwarding will break SPF, but not DKIM (one reason DMARC uses >> both). A mail provider that uses strict settings but doesn't DKIM >sign >> the messages would be considered seriously broken in my experience. >The >> issue is that many mailing list will break DKIM by slightly modifing >the >> message, like adding a signal word to the subject or a footer with >> information like unsubscribing instructions (this can be a legal >> requirement in some jurisdictions). Note, this list does NOT do this >> sort of modification, so doesn't cause that sort of problem. >> >> -- >> Richard Damon >> >>
