I would add that SRS itself is fairly useless, it was never adopted as a spec, and it's unlikely many people are going to do anything special with it. There was never any method given for how one would validate SRS, so the most one could do would be to say trust the SRS of a domain if the SPF reputation or IP reputation was above a certain threshold... but the usage of SRS is so low I doubt many folks would bother adding rules for it.
Using SRS to forward to Gmail is against our recommendations for forwarding, and yes, it will likely cause your domain to accumulate bad reputation for any spam you forward to us. I disagree with Vladimir that ARC requires a whitelist for trust, using a whitelist is certainly how I expect smaller operators and folks running their own servers to work. We think it's possible for an operator with sufficient mail volume to programmatically learn mailflows, assign reputations and build a trust framework. It should also be possible for operators to contract with third party vendors who have the expertise and/or volume to do that. We could also be wrong, that's one of the reasons the current plan is to publish the ARC RFC on the experimental track. Brandon On Thu, Nov 2, 2017 at 8:34 AM Vladimir Dubrovin via mailop < mailop@mailop.org> wrote: > > > ARC doesn't solve the problem either, because ARC requires trust to be > established between all signers in the chain and receiver of the mesage. > ARC doesn't provide any means to establish this trust. In short: ARC > will only work with the whitelist of known forwarders and it doesn't > contain any means to redistribute or update this whitelist. It's > intended product like OpenARC to be destributed with the whitelist of > known forwarders preloaded. > > It's quite sad people misunderstand this fact and believe ARC can > replace DMARC. It can not. ARC doesn't work without DMARC, because ARC > only ads whitelist and tracking functionality to DMARC. > > Currently, we have whitelists based on DKIM signatures / IP addresses of > known forwarders, so the profit from ARC is close to zero. It allows to > distinguish between forwarded and locally generated message and is > helpful in the case message is forwarded for multiple times. That's all. > > P.S. > Benoit provided the original message - it was a spam message with the > fake address, so it had no DKIM authentication. Forwarding message like > that with SRS to GMail gives negative reputation for both forwarding IP > and authorizing domain (one used for SRS). DMARC filter on forwarding > server could eliminate this problem. No problems are expected for real > message with DKIM authentication in current configuration. > > 02.11.2017 17:12, Ken O'Driscoll пишет: > > On Thu, 2017-11-02 at 13:28 +0100, Benoit Panizzon wrote: > >> How would one correctly implement email forwarding which works with all > >> kind of SPF, DKIM and DMARC Variants? > > Hi Benoit, > > > > Short answer - you can't. DMARC is simply not designed to facilitate any > > type of address re-writing or forwarding. > > > > As Vladimir points out, DKIM can sometimes prevail after an email is > > forwarded, but it can't be assumed. Plus, that DKIM signature must be > > already working and aligned to the original sending domain. > > > > DMARC also breaks mailing lists. Mailman "gets around" DMARC by > re-writing > > the From address to be that of the list and putting the original sender > in > > the Reply-To. Fine for mailing lists, not so fine for one-to-one emails > > etc. > > > > There is an emerging mechanism called ARC (http://arc-spec.org/) which > > addresses this restriction in DMARC to some degree in certain cases. Many > > providers, including Google, are already trialing ARC and it is being > > actively worked on. > > > > Ken. > > > > -- > > Ken O'Driscoll / We Monitor Email > > t: +353 1 254 9400 | w: www.wemonitoremail.com > > > > Need to understand deliverability? Now there's a book: > > www.wemonitoremail.com/book > > > > > > _______________________________________________ > > 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
