Yeah, there are two options for forwarding, to rewrite the envelope sender or not, and both seem pretty common.
Mailing lists almost always rewrite, so the sender doesn't get bounce reports for the entire list, and so the list can handle bouncing users by removing them. Granted, mailing lists usually do other things to break DMARC. Gmail's auto-forwarding rewrites so we can auto-disable forwarding if the next hop starts rejecting messages, and also for the privacy of the forwarder. GSuite's routing allows for both, since some forwarding you want to bounce with, and some (like for message archiving or whatever) you don't ever want to bounce to the sender. And our forwarding recommendations say to not rewrite so that you don't accumulate bad spam reputation if your spam filtering isn't perfect before forwarding. Breaking one half of those, when you have no idea what it is, seems bad. Granted, spam rules for last years outbreak of DKIM replays upped the benefits of SPF and harmed many types of forwarding. Brandon On Thu, Sep 7, 2017 at 7:39 AM, Vladimir Dubrovin via mailop < mailop@mailop.org> wrote: > > That's practically bad idea, you will not be able to send an e-mail to > user who has redirection to another account. If, for some reason, you > really want to implement it, you can remove DKIM signature or sign your > messages with unaligned DKIM domain. In this case DMARC only uses SPF > for authentication and fails on any redirection. > > 07.09.2017 16:50, Jesse Thompson пишет: > > What about the idea of extending DMARC to allow a domain owner to > > publish a policy that says "All email using my domain in the SMTP Mail > > From must be aligned to the From: header domain." DMARC already has > > the subdomain policy capability, and alignment could be achieved using > > DKIM or SPF for legitimate uses of the subdomain. > > > > It's a question I've been noodling on for a while without a good way > > to ask. It seems that the problem Terry describes is along those lines. > > > > Jesse > > > > On 8/30/2017 5:00 PM, Benjamin BILLON via mailop wrote: > >> You can also check Terry Zink's recent article on this topic, and > >> Bart's comment: > >> https://blogs.msdn.microsoft.com/tzink/2017/08/15/does-spf- > need-an-update-so-subdomains-can-inherit-the-policy-of-its- > organizational-domain-i-say-yes/ > >> > >> > >> > >> -- > >> <https://www.splio.com> > >> > >> > >> Benjamin > >> > >> 2017-08-30 23:09 GMT+08:00 Vladimir Dubrovin via mailop > >> <mailop@mailop.org <mailto:mailop@mailop.org>>: > >> > >> > >> > >> DMARC prevents usage of your subdomains in the From: header. SPF > >> doesn't protect it in anyway, it only checks SMTP envelope-from. > >> > >> 25.08.2017 17:11, Cameron Dixon via mailop пишет: > >>> Hello! I have a random question about SPF/DMARC and subdomains. > >>> > >>> openspf.org <http://openspf.org> [1] recommends that > >>> non-mail-sending domains have a "v=spf1 -all" record, which can be > >>> pretty onerous if you have a lot of names published in DNS. > >>> > >>> The DMARC RFC indicates you can set a policy specific for > >>> subdomains [2]. If sp=reject is set at _dmarc.example.tld (and > >>> there isn't an overriding policy at the host itself, since it gets > >>> checked first [3]), would this would be an effective way to > >>> disclaim email coming subdomains and not need to add SPF records > >>> across the zone? > >>> > >>> - - - - > >>> Cameron > >>> > >>> > >>> [1] http://www.openspf.org/FAQ/Common_mistakes#all-domains > >>> <http://www.openspf.org/FAQ/Common_mistakes#all-domains> (last > >>> updated 2009) > >>> [2] https://tools.ietf.org/html/rfc7489#section-6.3 > >>> <https://tools.ietf.org/html/rfc7489#section-6.3> > >>> [3] https://tools.ietf.org/html/rfc7489#section-6.6.3 > >>> <https://tools.ietf.org/html/rfc7489#section-6.6.3> > >>> > >>> > >>> _______________________________________________ > >>> mailop mailing list > >>> mailop@mailop.org <mailto:mailop@mailop.org> > >>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >>> <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop> > >> > >> > >> -- Vladimir Dubrovin > >> @Mail.Ru > >> > >> > >> _______________________________________________ > >> mailop mailing list > >> mailop@mailop.org <mailto:mailop@mailop.org> > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >> <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop> > >> > >> > >> > >> > >> _______________________________________________ > >> mailop mailing list > >> mailop@mailop.org > >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >> > > > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > -- > Vladimir Dubrovin > @Mail.Ru > > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
