Re: [mailop] mail.ru google and DMARC

[Vladimir Dubrovin via mailop]

> 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.

Yes, ARC is useful for big guys like GMail, cause we can automate things
and anyway we get new entity to use in antispam and it's useful to
decrease the number of type I/II errors.
The problem here is failed expectations for community. Mailing list
administrator has DMARC issues and he believes ARC to fix the problem.
Currently, things are simple: if sender's domain has stong DMARC,
rewrite From address.
ARC only makes things more complex for mailing list administrator. He
can not know if receiving side
a) supports ARC
b) trusts his domain
and there is no way for recipient to indicate it.
So, any mailing list administrator is forced to maintain (another one)
whitelist of domains where ARC (or may be DKIM/SPF/IP whitelist or good
karma or absence of DMARC filtering on receiving side - cause he can not
know exactly) actually works for him, and he still needs to rewrite From
for all other recipients. The things are worsened by the fact this list
is not redistributable, because you can know (a), but you can not know
(b) and (b) can change in time or depend on message class, the only way
for mailing lists administrator is to compile this list by trial and
error. In the case of "quarantine" DMARC policy there is no way at all
except registering box in every domain.



03.11.2017 1:28, Brandon Long via mailop пишет:
> 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
> > 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
>  

Re: [mailop] mail.ru google and DMARC

[Brandon Long via mailop]

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

Re: [mailop] mail.ru google and DMARC

[Vladimir Dubrovin via mailop]

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

Re: [mailop] mail.ru google and DMARC

[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

Re: [mailop] mail.ru google and DMARC

[Vladimir Dubrovin via mailop]

SPF record is OK, see https://tools.ietf.org/html/rfc7208#section-3.3

mail.ru publishes strict DMARC policy (reject) to prevent spoofing.

DMARC requires alignment between SPF authenticated domain and domain
from RFC5322.From
You perform SRS, so message you send is SPF-authenticated by your
domain, but this domain is not aligned with mail.ru domain from
RFC5322.From. Any redirecton makes SPF useless for DMARC.

DKIM is intended to fix this problem, and the real issue here is you
probably break DKIM signature of the message. It can happen if you
change content of the message or headers, by e.g. modifying Subject: or
adding something to mail body.

Can you diff original message and forwarded one to find possible
modifications?


02.11.2017 15:28, Benoit Panizzon пишет:
> Dear List
>
> I have come across a strange problem.
>
> One of our customers is forwarding his emails to his google account.
>
> We do implement SRS to rewrite the envelope sender to match our SPF
> record.
> All other headers are preserved, in case they are DKIM Signed.
>
> Google rejects the emails with:
>
> : host
> gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
> Unauthenticated email from mail.ru is not accepted due to domain's
> 550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
> domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
> https://support.google.com/mail/answer/2451690 to learn about the
> 550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
> of DATA command)
>
> Ok I have not yet stumbled over a lot of email senders using DMARC. So
> I read on: https://en.wikipedia.org/wiki/DMARC
>
> Did I get that right? DMARC checks that the envelope-from and From:
> header are 'aligned'?
>
> Well how the hell should that work when an email is being forwarded?
>
> SPF requires that I rewrite the envelope sender, DKIM requires that I
> don't alter the signed From: Header, DMARC requires that I do alter the
> From: Header?
>
> And where the heck does mail.ru publish it's DMARC policy via DNS?
>
> mail.ru has address 217.69.139.201
> mail.ru has address 94.100.180.201
> mail.ru has address 217.69.139.200
> mail.ru has address 94.100.180.200
> mail.ru name server ns3.mail.ru.
> mail.ru name server ns1.mail.ru.
> mail.ru name server ns2.mail.ru.
> mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
> 900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
> mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
> mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1
>
> _spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
> ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
> ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
> ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
> ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
> ip4:5.61.239.144/32 ~all"
>
> Well his somehow looks like a broken SPF record. Anyway ~all would
> specify softfail and not reject.
>
> Can anyone help putting the puzzle together?
>
> How would one correctly implement email forwarding which works with all
> kind of SPF, DKIM and DMARC Variants?
>
> And yes I know, email forwarding is considered bad(tm), but it is still
> widely used.
>
> -Benoît Panizzon-


-- 
Vladimir Dubrovin
@Mail.Ru



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mail.ru google and DMARC

[David Hofstee]

> And where the heck does mail.ru publish it's DMARC policy via DNS?

dig txt _dmarc.mail.ru



David

On 2 November 2017 at 13:28, Benoit Panizzon  wrote:

> Dear List
>
> I have come across a strange problem.
>
> One of our customers is forwarding his emails to his google account.
>
> We do implement SRS to rewrite the envelope sender to match our SPF
> record.
> All other headers are preserved, in case they are DKIM Signed.
>
> Google rejects the emails with:
>
> : host
> gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
> Unauthenticated email from mail.ru is not accepted due to domain's
> 550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
> domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
> https://support.google.com/mail/answer/2451690 to learn about the
> 550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
> of DATA command)
>
> Ok I have not yet stumbled over a lot of email senders using DMARC. So
> I read on: https://en.wikipedia.org/wiki/DMARC
>
> Did I get that right? DMARC checks that the envelope-from and From:
> header are 'aligned'?
>
> Well how the hell should that work when an email is being forwarded?
>
> SPF requires that I rewrite the envelope sender, DKIM requires that I
> don't alter the signed From: Header, DMARC requires that I do alter the
> From: Header?
>
> And where the heck does mail.ru publish it's DMARC policy via DNS?
>
> mail.ru has address 217.69.139.201
> mail.ru has address 94.100.180.201
> mail.ru has address 217.69.139.200
> mail.ru has address 94.100.180.200
> mail.ru name server ns3.mail.ru.
> mail.ru name server ns1.mail.ru.
> mail.ru name server ns2.mail.ru.
> mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
> 900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
> mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
> mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1
>
> _spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
> ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
> ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
> ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
> ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
> ip4:5.61.239.144/32 ~all"
>
> Well his somehow looks like a broken SPF record. Anyway ~all would
> specify softfail and not reject.
>
> Can anyone help putting the puzzle together?
>
> How would one correctly implement email forwarding which works with all
> kind of SPF, DKIM and DMARC Variants?
>
> And yes I know, email forwarding is considered bad(tm), but it is still
> widely used.
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



-- 
--
My opinion is mine.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] mail.ru google and DMARC

[Benoit Panizzon]

Dear List

I have come across a strange problem.

One of our customers is forwarding his emails to his google account.

We do implement SRS to rewrite the envelope sender to match our SPF
record.
All other headers are preserved, in case they are DKIM Signed.

Google rejects the emails with:

: host
gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
Unauthenticated email from mail.ru is not accepted due to domain's
550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
https://support.google.com/mail/answer/2451690 to learn about the
550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
of DATA command)

Ok I have not yet stumbled over a lot of email senders using DMARC. So
I read on: https://en.wikipedia.org/wiki/DMARC

Did I get that right? DMARC checks that the envelope-from and From:
header are 'aligned'?

Well how the hell should that work when an email is being forwarded?

SPF requires that I rewrite the envelope sender, DKIM requires that I
don't alter the signed From: Header, DMARC requires that I do alter the
From: Header?

And where the heck does mail.ru publish it's DMARC policy via DNS?

mail.ru has address 217.69.139.201
mail.ru has address 94.100.180.201
mail.ru has address 217.69.139.200
mail.ru has address 94.100.180.200
mail.ru name server ns3.mail.ru.
mail.ru name server ns1.mail.ru.
mail.ru name server ns2.mail.ru.
mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1

_spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
ip4:5.61.239.144/32 ~all"

Well his somehow looks like a broken SPF record. Anyway ~all would
specify softfail and not reject.

Can anyone help putting the puzzle together?

How would one correctly implement email forwarding which works with all
kind of SPF, DKIM and DMARC Variants?

And yes I know, email forwarding is considered bad(tm), but it is still
widely used.

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop