[dmarc-discuss] Disposition none on policy reject when DKIM and SPF fail

[Dorai Ashok S A]

Hi,

In the last few months, I have noticed a few unauthorized email messages
being accepted even though DMARC and SPF checks fail. In the DMARC
report, reason is mentioned as "forwarded". I have search around a lot
on this and I haven't been able to find a solution. Hence trying to seek
some help here.

Could someone explain what "forwarded" means when DMARC policy is
"reject" ? and How do i enforce the "reject" policy in such cases ?

I have listed down the information I have in the DMARC report below for
your reference,

Policy Published:

<policy_published>
<domain>mpipe.net</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>

Record:

<record>
<row>
<source_ip>192.185.4.17</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>mpipe.net</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mpipe.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>

NOTE: 192.185.4.17 is an *Unauthorized* sender.

Regards,
-Ashok.

[Tim Draegen]

Hi -Ashok.,

The "forwarded" reason is supposed to mean Why your requested policy was not applied.

This is typically used when a receiver knows that email is coming in from a service that people use to scan/clean... or forward.. email.

Keep in mind that email Receivers will always be free to apply whatever policy they want. In your case, the receiver has added an exception for that specific server because, from their perspective, legitimate email is flowing in to their infrastructure from that server (even though authentication is being broken). If they didn't apply this exception, then legitimate email would fail to be delivered, and likely incur support costs.

HTH,
=- Tim

PS. I don't think you can do anything, except if you have evidence that the server is NOT a forwarder.

Hi,
In the last few months, I have noticed a few unauthorized email messages being accepted even though DMARC and SPF checks fail. In the DMARC report, reason is mentioned as "forwarded". I have search around a lot on this and I haven't been able to find a solution. Hence trying to seek some help here.
Could someone explain what "forwarded" means when DMARC policy is "reject" ? and How do i enforce the "reject" policy in such cases ?
I have listed down the information I have in the DMARC report below for your reference,
<policy_published>
<domain>mpipe.net</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.185.4.17</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>mpipe.net</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mpipe.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
NOTE: 192.185.4.17 is an *Unauthorized* sender.
Regards,
-Ashok.

[Dorai Ashok S A]

Hi Tim,

I understand that the receivers are free to apply whatever policy they
want. However, in line with DMARC, I would expect receivers to follow
some guidelines. I am really interested in these guidelines so that I
can configure my mail server correctly.

In this particular case, I was able to confirm that the email didn't
originate from @mpipe.net. So, it was an unsolicited email.

I understand from your response that the receiver giving a reason
"forwarder" is kind of like a special case which they want to handle
correctly. Although, I wish DMARC provided some way of saying, no
special cases. After all, senders do get a failure message when the
email gets rejected at the SMTP layer due to DMARC.

Is there a way of saying no special cases in DMARC ?

Regards,
-Ashok.

Post by Tim Draegen
Hi -Ashok.,
The "forwarded" reason is supposed to mean Why your requested policy was not applied.
This is typically used when a receiver knows that email is coming in from a service that people use to scan/clean... or forward.. email.
Keep in mind that email Receivers will always be free to apply whatever policy they want. In your case, the receiver has added an exception for that specific server because, from their perspective, legitimate email is flowing in to their infrastructure from that server (even though authentication is being broken). If they didn't apply this exception, then legitimate email would fail to be delivered, and likely incur support costs.
HTH,
=- Tim
PS. I don't think you can do anything, except if you have evidence that the server is NOT a forwarder.

Hi,
In the last few months, I have noticed a few unauthorized email messages being accepted even though DMARC and SPF checks fail. In the DMARC report, reason is mentioned as "forwarded". I have search around a lot on this and I haven't been able to find a solution. Hence trying to seek some help here.
Could someone explain what "forwarded" means when DMARC policy is "reject" ? and How do i enforce the "reject" policy in such cases ?
I have listed down the information I have in the DMARC report below for your reference,
<policy_published>
<domain>mpipe.net</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.185.4.17</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>mpipe.net</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mpipe.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
NOTE: 192.185.4.17 is an *Unauthorized* sender.
Regards,
-Ashok.

[J. Gomez]

Post by Dorai Ashok S A
Hi Tim,
I understand that the receivers are free to apply whatever policy they
want. However, in line with DMARC, I would expect receivers to follow
some guidelines. I am really interested in these guidelines so that I
can configure my mail server correctly.
In this particular case, I was able to confirm that the email didn't
I understand from your response that the receiver giving a reason
"forwarder" is kind of like a special case which they want to handle
correctly. Although, I wish DMARC provided some way of saying, no
special cases. After all, senders do get a failure message when the
email gets rejected at the SMTP layer due to DMARC.
Is there a way of saying no special cases in DMARC ?

Not that I know of.

As DMARC breaks mailing lists, DMARC-aware receivers will always apply local policies to override DMARC policy p=reject as per each receiver's secret-sauce in-house recipe.

So you can publish DMARC p=reject, but it is going to mean little to the world, because the world just cannot trust that you REALLY mean a DMARC policy of p=reject when you publish it. Perhaps when DMARC is more widely known that in-the-trenches reality will change.

Google as a receiver currently applies their own secret-sauce policy to sender's DMARC policy of p=reject, and the rest follow.

Regards,

J.Gomez

[Tim Draegen]

Post by J. Gomez

Post by Dorai Ashok S A
Is there a way of saying no special cases in DMARC ?

Not that I know of.

I tried to clarify in previous post why the ability to add "no special cases" doesn't help the situation. In short, "no special cases" as expressed by a domain owner doesn't help the receiver as they deal with the complexity of how email flows into their infrastructure.

Post by J. Gomez
As DMARC breaks mailing lists, DMARC-aware receivers will always apply local policies to override DMARC policy p=reject as per each receiver's secret-sauce in-house recipe.

The above statement is almost accurate. DMARC-aware receivers can apply local policies to override DMARC policy when it makes sense from their perspective to do so. EG: override for recognized mailing lists or forwarding. It's there for a reason.

Post by J. Gomez
So you can publish DMARC p=reject, but it is going to mean little to the world, because the world just cannot trust that you REALLY mean a DMARC policy of p=reject when you publish it. Perhaps when DMARC is more widely known that in-the-trenches reality will change.

The above is not true. Receivers supply feedback to domain owners so that domain owners can accurately implement email authentication. The "social contract" in place is that receivers will enforce p=reject policies when requested by domain owners because this feedback is made available to domain owners. This is how trust between receivers and domain owners is created.

J.Gomez, as an experiment you might try attempting to deliver unauthenticated email for a p=reject domain into a DMARC-compliant receiver. The experiment might change how you write about the world and in-the-trenches reality.

Post by J. Gomez
Google as a receiver currently applies their own secret-sauce policy to sender's DMARC policy of p=reject, and the rest follow.

"Secret sauce" is usually applied to how receivers determine what is spam vs what is not. Spammers want to know what they need to do to avoid being identified as "spammer", and so the shield of secrecy... secret sauce... was born to avoid telling spammers how to avoid detection.

In the context of DMARC, Google's internal methods of determine what are mailing lists and where forwarded email comes from is probably better considered as "internal methods of detecting emailing lists and forwarded email". Definitely not secret-sauce, as Google will happily tell you when they think they get your email via mailing list and/or forwarding... they include this in their DMARC-XML reports.

Just trying to be helpful,
=- Tim

[Tim Draegen]

Post by Dorai Ashok S A
Hi Tim,
I understand that the receivers are free to apply whatever policy they want. However, in line with DMARC, I would expect receivers to follow some guidelines. I am really interested in these guidelines so that I can configure my mail server correctly.

Ashok., I'm glad the "receivers do they want" thing is clear. This is often problematic for senders to get used to.

Unfortunately, there are no guidelines for what receivers do when determining what boils down to be their own local policy. DMARC is forcing these questions to come up, but so far these questions haven't coalesced into a set of guidelines.
This could be a difficult thing to discover. You may have delivered to another domain, and that domain then forwarded onto hostgator.com infrastructure (192.185.4.17), which then ultimately delivered email to the DMARC-receiver that provided you with the report.

Or, it might be a hole that fraud is exploiting to get around DMARC controls. Without some form of copy of the email under question, you just can't know for sure.

Post by Dorai Ashok S A
I understand from your response that the receiver giving a reason "forwarder" is kind of like a special case which they want to handle correctly. Although, I wish DMARC provided some way of saying, no special cases. After all, senders do get a failure message when the email gets rejected at the SMTP layer due to DMARC.

I'm not sure such a DMARC-based flag would be useful. The DMARC social-contract is that receivers provide data back to domain owners, and domain owners use that data to inform their authentication practices. Receivers can then freely apply DMARC policies with the understanding that support costs can be pushed back to domain owners.

There are circumstances where email flows beyond the control of both receivers AND domain owners, and for those circumstances the "reason"/override is in place to let domain owners know why their policies were not applied.

Against that backdrop, a policy like "p=reject-no-special-cases" isn't useful... "p=reject" does the same thing.

Take care,
=- Tim

Post by Dorai Ashok S A
Is there a way of saying no special cases in DMARC ?
Regards,
-Ashok.

[Dorai Ashok S A]

[Response Inline]

Post by Tim Draegen

Post by Dorai Ashok S A
I understand from your response that the receiver giving a reason "forwarder" is kind of like a special case which they want to handle correctly. Although, I wish DMARC provided some way of saying, no special cases. After all, senders do get a failure message when the email gets rejected at the SMTP layer due to DMARC.

I'm not sure such a DMARC-based flag would be useful. The DMARC social-contract is that receivers provide data back to domain owners, and domain owners use that data to inform their authentication practices. Receivers can then freely apply DMARC policies with the understanding that support costs can be pushed back to domain owners.
There are circumstances where email flows beyond the control of both receivers AND domain owners, and for those circumstances the "reason"/override is in place to let domain owners know why their policies were not applied.
Against that backdrop, a policy like "p=reject-no-special-cases" isn't useful... "p=reject" does the same thing.

You have a valid point here. I now understand why the receiver gives a
reason "forwarder" and accepts the emails. I just hope its not exploited
to get around DMARC controls.

And, thanks for the detailed response, Tim. It was very helpful.

Regards,
-Ashok.

Post by Tim Draegen
Take care,
=- Tim

[Roland Turner]

Post by Dorai Ashok S A
You have a valid point here. I now understand why the receiver gives a
reason "forwarder" and accepts the emails. I just hope its not
exploited to get around DMARC controls.

I meant to comment on this earlier.

DMARC appears to draw an unavoidable parallel with access control
mechanisms in the minds of Domain Owners frustrated by the abuse of
their domain names (e.g.: your first post used words like "enforce" and
"unauthorized", the latter in bold). This is perhaps unavoidable, but
things may run more smoothly if we ever come up with a way to more
accurately communicate DMARC's intention to those who encounter it for
the first time.

DMARC is best understood not as the FUSSP but as a pragmatic tool that
helps Domain Owners and receivers co-operate on an otherwise-intractable
problem, consequently it doesn't attempt to solve the entire spoofing
problem, it merely attempts to make progress on part of the problem. The
fact that the real-world email system contains situations where DMARC
can't make decisions as accurately as Domain Owners and receivers would
like (e.g. legitimate forwarders and independent senders exist and
engage in a variety of perfectly reasonable behaviours that don't mesh
well with DMARC) isn't a vulnerability in DMARC (i.e. something that can
be "exploited"), it's just a problem that DMARC doesn't purport to solve.

It is worth noting that any large scale spoofing via a poorly-secured
forwarder or independent sender would cause most receivers to cease
exempting them from DMARC processing anyway. This difficulty is largely
self-correcting.

- Roland

[J. Gomez]

Post by Roland Turner

Post by Dorai Ashok S A
You have a valid point here. I now understand why the receiver
gives a reason "forwarder" and accepts the emails. I just hope its
not exploited to get around DMARC controls.

I meant to comment on this earlier.
DMARC appears to draw an unavoidable parallel with access control
mechanisms in the minds of Domain Owners frustrated by the abuse of
their domain names (e.g.: your first post used words like "enforce" and
"unauthorized", the latter in bold). This is perhaps unavoidable, but
things may run more smoothly if we ever come up with a way to more
accurately communicate DMARC's intention to those who encounter it for
the first time.
DMARC is best understood not as the FUSSP but as a pragmatic tool that
helps Domain Owners and receivers co-operate on an
otherwise-intractable
problem, consequently it doesn't attempt to solve the entire spoofing
problem, it merely attempts to make progress on part of the problem. The
fact that the real-world email system contains situations where DMARC
can't make decisions as accurately as Domain Owners and receivers would
like (e.g. legitimate forwarders and independent senders exist and
engage in a variety of perfectly reasonable behaviours that don't mesh
well with DMARC) isn't a vulnerability in DMARC (i.e. something that can
be "exploited"), it's just a problem that DMARC doesn't purport to solve.

So, in other words, there is not such a thing as a POLICY of REJECT in DMARC; and if there was ever one, you just cannot trust it nor follow it (as a receiver).

At least we still have the reporting feature of DMARC, as something which is actually useful (for the senders).

Regards,

J.Gomez

[Franck Martin]

Post by J. Gomez
So, in other words, there is not such a thing as a POLICY of REJECT in DMARC; and if there was ever one, you just cannot trust it nor follow it (as a receiver).
At least we still have the reporting feature of DMARC, as something which is actually useful (for the senders).

This is fundamentally misrepresenting DMARC by making people believe that edge cases are generalities and making people believe that a convenience feature to bolster early adoption is a fundamental flaw. The data is against you, DMARC is working well to stop spoofing at the receiver who adopted it, and yes there is still work to do, but the fundamentals are there. DMARC, improved DKIM interactions between MTA, improved forwarding in several places. DMARC does not work out of the box, until you take control of your email streams, for some organization this is easy, for some others it requires a lot of work. It is all then a question of priority and risk assessment.

[Murray S. Kucherawy]

Post by J. Gomez
So, in other words, there is not such a thing as a POLICY of REJECT in
DMARC; and if there was ever one, you just cannot trust it nor follow it
(as a receiver).

That's just a little bit hyperbolic. By extension, there's no such thing
as "-all" in SPF or "dkim=discardable" in ADSP.

Post by J. Gomez
At least we still have the reporting feature of DMARC, as something which
is actually useful (for the senders).

There are several examples of senders that find the policy action useful
because some key receivers do act on it. The same goes at least for SPF or
any advanced use of DKIM.

Honoring a "p=reject" might require more than zero thought. Unfortunately,
that scares some people more than it probably should.

-MSK

[Roland Turner]

Post by Murray S. Kucherawy
Honoring a "p=reject" might require more than zero thought.

+1

- Roland

[Jonas Falck - Halon Security Inc]

Agree!



Best Regards,

Jonas Falck
CEO & Co-Founder

HALON SECURITY INC
100 Montgomery Street, Suite 1080
San Francisco, CA 94104, USA
Phone: [phone]
Cell: +1.650.445.9076


***@halonsecurity.com
www.halonsecurity.com
www.inumbo.com

Post by Roland Turner

Post by Murray S. Kucherawy
Honoring a "p=reject" might require more than zero thought.

+1
- Roland
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: [phone] | Skype: roland.turner
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[Steven M Jones]

Post by J. Gomez
So, in other words, there is not such a thing as a POLICY of REJECT in
DMARC; and if there was ever one, you just cannot trust it nor follow
it (as a receiver).

Funny, the latter part of that statement is what I remember the large
receivers telling me ~10 years ago when I asked them to block messages
that failed SPF checks. The assertion being that they couldn't trust
that senders correctly understood or implemented SPF records and the
impact they would have. I view DMARC as the result of senders and
receivers working together to find a way to make that blocking possible
for many, but not all, cases.

DMARC can very effectively block abusive messages at scale. Where almost
all spurious messages were being allowed through for a particular domain
before publishing a "p=reject", less than 1% were being allowed through
after publishing that record. And yes, that's even with any "secret
sauce policies" or exceptions previously mentioned in this thread. We're
talking about millions of fraudulent messages being kept out of
mailboxes, and I'll take those actual results every time over any
quibbles about DMARC's design.

Thank goodness the receivers see the value in dedicating the manpower
and resources it takes to implement their side of it even if they "just
cannot trust it" - I'll continue to do so on the sender side where ever
I can.

--S.

[Roland Turner]

Post by J. Gomez

Post by Roland Turner
DMARC is best understood not as the FUSSP but as a pragmatic tool that
helps Domain Owners and receivers co-operate on an
otherwise-intractable
problem, consequently it doesn't attempt to solve the entire spoofing
problem, it merely attempts to make progress on part of the problem. The
fact that the real-world email system contains situations where DMARC
can't make decisions as accurately as Domain Owners and receivers would
like (e.g. legitimate forwarders and independent senders exist and
engage in a variety of perfectly reasonable behaviours that don't mesh
well with DMARC) isn't a vulnerability in DMARC (i.e. something that can
be "exploited"), it's just a problem that DMARC doesn't purport to solve.

So, in other words, there is not such a thing as a POLICY of REJECT in DMARC;

As others have pointed out, this is simply false. I may have a policy
that you give all of your money to me simply for continuing to read this
message, that doesn't mean that you will do so. The fact that you don't
do so doesn't mean that the policy doesn't exist, simply that it's not
binding upon you.

DMARC policies are similarly non-binding upon receivers. A Domain Owner
can have a range of policies and options (p, sp, pct). No such policy is
ever binding upon a receiver because the latter owns (and indeed, pays

[Matt Simerson]

Hi Ashok,

The most likely explanation is that someone @mpipe.net is sending email *to* someone that has an email box with an MX of gator4006.hostgator.com (192.185.4.17). That server receives the email message and then forwards it on to the recipients mailbox. This is a very common practice, and it looks to the final recipient as if 192.185.4.17 is sending mail from your domain. Technically, it is, but forwards are an edge case that the recipients mail server knows about and decided to pass anyway, despite the DMARC failure.

Matt

Hi,
In the last few months, I have noticed a few unauthorized email messages being accepted even though DMARC and SPF checks fail. In the DMARC report, reason is mentioned as "forwarded". I have search around a lot on this and I haven't been able to find a solution. Hence trying to seek some help here.
Could someone explain what "forwarded" means when DMARC policy is "reject" ? and How do i enforce the "reject" policy in such cases ?
I have listed down the information I have in the DMARC report below for your reference,
<policy_published>
<domain>mpipe.net</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.185.4.17</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>mpipe.net</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mpipe.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
NOTE: 192.185.4.17 is an *Unauthorized* sender.
Regards,
-Ashok.
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[Dorai Ashok S A]

Hi Matt,

I too thought of the same and scanned the logs. But, there was no email
sent out from @mpipe.net to MX of gator4006.hostgator.com. And, since
all the emails sent from @mpipe.net are DKIM signed. I would expect the
DKIM verification to atleast be successful. However, in this case, I am
guessing, there was no DKIM signature. All this seems to indicate that
it was an unsolicited email.

Also, Considering forwards are being accepted by recipients mail server
irrespective of DMARC policy, wouldn't it be a loop hole in DMARC that
can be easily exploited ?

Is there, by any chance, a provision in DMARC or SPF to mention
authorized forwarders ?

Regards,
-Ashok.

Post by Matt Simerson
Hi Ashok,
Matt

Hi,
In the last few months, I have noticed a few unauthorized email messages being accepted even though DMARC and SPF checks fail. In the DMARC report, reason is mentioned as "forwarded". I have search around a lot on this and I haven't been able to find a solution. Hence trying to seek some help here.
Could someone explain what "forwarded" means when DMARC policy is "reject" ? and How do i enforce the "reject" policy in such cases ?
I have listed down the information I have in the DMARC report below for your reference,
<policy_published>
<domain>mpipe.net</domain>
<adkim>s</adkim>
<aspf>s</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.185.4.17</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>mpipe.net</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mpipe.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
NOTE: 192.185.4.17 is an *Unauthorized* sender.
Regards,
-Ashok.
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[John Levine]

Post by Roland Turner
It is worth noting that any large scale spoofing via a poorly-secured
forwarder or independent sender would cause most receivers to cease
exempting them from DMARC processing anyway. This difficulty is largely
self-correcting.

Quite right. DMARC is just advice from a domain owner to a recipient,
and the best advice to give is whatever will make the recipients happy.

In particular, this does not include telling people to throw away
perfectly good mail just because it went via a path you don't control.

R's,
John

[Franck Martin]

Post by John Levine

Post by Roland Turner
It is worth noting that any large scale spoofing via a poorly-secured
forwarder or independent sender would cause most receivers to cease
exempting them from DMARC processing anyway. This difficulty is largely
self-correcting.

Quite right. DMARC is just advice from a domain owner to a recipient,
and the best advice to give is whatever will make the recipients happy.
In particular, this does not include telling people to throw away
perfectly good mail just because it went via a path you don't control.

and neither party (sender or receiver) can fix.

[Rolf E. Sonneveld]

Post by Franck Martin

Post by John Levine

Post by Roland Turner
It is worth noting that any large scale spoofing via a poorly-secured
forwarder or independent sender would cause most receivers to cease
exempting them from DMARC processing anyway. This difficulty is largely
self-correcting.

Quite right. DMARC is just advice from a domain owner to a recipient,
and the best advice to give is whatever will make the recipients happy.
In particular, this does not include telling people to throw away
perfectly good mail just because it went via a path you don't control.

and neither party (sender or receiver) can fix.

at a reasonable cost.

[John Levine]

Post by J. Gomez
So, in other words, there is not such a thing as a POLICY of REJECT in DMARC; and if there was ever one,
you just cannot trust it nor follow it (as a receiver).

Generally speaking, yes. I expect that many receivers manage their
own meta-policies, to decide whose published DMARC policies are worth
following.

If Paypal says to reject, I'm inclined to do it. If it's Linkedin,
I'm not.

R's,
John

[Tim Draegen]

Post by John Levine

Post by J. Gomez
So, in other words, there is not such a thing as a POLICY of REJECT in DMARC; and if there was ever one,
you just cannot trust it nor follow it (as a receiver).

I have to chime in here before the masses get insanely confused: the above quote is incorrect.

1. DMARC *does* have both a "reject" and a "quarantine" policy built into it. You *can* trust it, but you (as a receiver) also have to know what you are doing.

Post by John Levine
Generally speaking, yes. I expect that many receivers manage their
own meta-policies, to decide whose published DMARC policies are worth
following.

2. The above is 1/2 right. Receivers do need to manage their own policies. The wrong part is making the decision point "whose published DMARC policies are worth following", when it should be "where does email flow beyond control of domain owners".

To avoid going in circles, I'll reference a previous email:

http://www.dmarc.org/pipermail/dmarc-discuss/2014-February/002336.html

Search for "There are circumstances where email flows beyond the control of both receivers AND domain owners" and maybe read a paragraph plus or minus.


You guys are accumulating a bit of history of not really talking about DMARC, but instead asserting random things that aren't true, and then disappearing when asked to do some homework.

Post by John Levine
If Paypal says to reject, I'm inclined to do it. If it's Linkedin,
I'm not.

Both LinkedIn and PayPal are doing incredible work to make email more resilient to fraud, and they both encounter similar issues. As I wrote above, if you're basing your decision to enforce DMARC policies on mailing list traffic, you're absolutely doing it wrong. For more information (homework!), see the last 2 paragraphs of:

http://www.dmarc.org/pipermail/dmarc-discuss/2014-February/002337.html

Just trying to help,
=- Tim

[J. Gomez]

Post by Tim Draegen
You guys are accumulating a bit of history of not really talking
about DMARC, but instead asserting random things that aren't true,
and then disappearing when asked to do some homework.

Is it true that if you reject incoming email which fails DMARC validation and whose sender's policy is REJECT, then you are in for a world of hurt? Yes, it is true. Therefore, DMARC'S p=reject is not something you can trust, nor follow. Period. There is no clothing that puppet that is going to change this truth about DMARC

You can feed a DMARC result of fail plus p=reject as score input into some system to apply some locally crafted algorithms to determine the probability of spamminess/phising, but then your are still not following the stated POLICY of REJECT in the sender's DMARC. That is a truth. About DMARC.

You can point to links which say "all is relative", "take it with a grain of salt", etc. That's fine. That, however, does not change the truth that you cannot trust nor follow DMARC's POLICY of REJECT. You, at most, can take it into account as a score/weight to do further local processing - OK, but you are then not REJECTing as per the sender's DMARC policy. Undeniable truth, that.

It is the DMARC specification that chose to call it "policy", not "recommendation". And policy is a policy, not a suggestion. Twisting words to fit ex-post facto scenarios/realities is not funny.

Perhaps you can spend your whole working day, day after day, fine tuning your local DMARC processing secret-sauce. Good for you. Other people do not have that luxury.

Regards,
J.Gomez

[Franck Martin]

Post by J. Gomez

Post by Tim Draegen
You guys are accumulating a bit of history of not really talking
about DMARC, but instead asserting random things that aren't true,
and then disappearing when asked to do some homework.

Is it true that if you reject incoming email which fails DMARC validation and whose sender's policy is REJECT, then you are in for a world of hurt? Yes, it is true. Therefore, DMARC'S p=reject is not something you can trust, nor follow. Period. There is no clothing that puppet that is going to change this truth about DMARC

Then don't. It is normal for a receiver to assert the sender policy, and bounce the email. The sender can correct or not, but as there is a feedback loop, the receiver does not need to second guess the sender policy.

This is this concept that you fail to grasp.

If forwarded emails do not reach their destination, the sender knows about it, and asserted it did not matter compared to the spoofing problem they have. There is no world of hurt. So your first axiom is false. No need to continue further.

I think, time to closes these threads. We obviously won't change your mind and I guess people on the list have had enough info to form an opinion.

[Paul Midgen]

i'm late to the party, i guess. but this got my attention. what data backs
this statement up? i'm curious because it asserts exactly the opposite of
what we (DMARC core group) saw in 2 years of private testing on DMARC prior
to releasing it to the public.

Post by J. Gomez

Post by J. Gomez
if you reject incoming email which fails DMARC validation and whose

sender's policy is REJECT, then you are in for a world of hurt

[Matt Simerson]

Post by J. Gomez

Post by Tim Draegen
You guys are accumulating a bit of history of not really talking
about DMARC, but instead asserting random things that aren't true,
and then disappearing when asked to do some homework.

Is it true that if you reject incoming email which fails DMARC validation and whose sender's policy is REJECT, then you are in for a world of hurt? Yes, it is true.

True? I shovel male cow excrement upon your assertion.

Applying p=reject on behalf of senders that ask for it barely ever hurts. If ever.

I have been using DMARC validation in production for 10 months. When a message results in a DMARC p=reject policy, I reject it. Period. I have the ability to override DMARC policy, and I have the ability to exempt connections from DMARC policy using a whitelist. I have used the whitelist for exactly two IP addresses in 10 months, and in both cases it was for testing commercial mail filtering appliances (trusted forwarders) in front of my mail server.

I have the ability to easily apply locally crafted algorithms to determine the probability of ham/spam for any given connection and/or message. I disable SMTP rejections for mail plugins that frequently false positive (DNSBL, SPF, DKIM, GeoIP, FCrDNS, header validity) and instead apply heuristics scoring to plugin results. DMARC remains one of the few plugins that I allow to reject connections on its own.

A DMARC policy of p=reject can be followed. Senders that publish such policies [will soon] know that their messages that transit certain list servers that insist upon breaking DKIM signatures will end up rejected. If the sender is willing to live with that, the receiver should be too.

Matt

Post by J. Gomez
Therefore, DMARC'S p=reject is not something you can trust, nor follow. Period. There is no clothing that puppet that is going to change this truth about DMARC
You can feed a DMARC result of fail plus p=reject as score input into some system to apply some locally crafted algorithms to determine the probability of spamminess/phising, but then your are still not following the stated POLICY of REJECT in the sender's DMARC. That is a truth. About DMARC.
You can point to links which say "all is relative", "take it with a grain of salt", etc. That's fine. That, however, does not change the truth that you cannot trust nor follow DMARC's POLICY of REJECT. You, at most, can take it into account as a score/weight to do further local processing - OK, but you are then not REJECTing as per the sender's DMARC policy. Undeniable truth, that.
It is the DMARC specification that chose to call it "policy", not "recommendation". And policy is a policy, not a suggestion. Twisting words to fit ex-post facto scenarios/realities is not funny.
Perhaps you can spend your whole working day, day after day, fine tuning your local DMARC processing secret-sauce. Good for you. Other people do not have that luxury.
Regards,
J.Gomez
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[Matt Simerson]

Absolutely.

Matt's message, as evaluated by Gmail, failed alignment, and was consequently marked as spam.

Thanks to DMARC reports, the sender is quite aware. Of course I'd prefer that this list didn't invalidate my DKIM signatures. I'd also prefer that Google's SPF recognized that this list server is SPF permitted for @tnpi.net. But that's outside my ability to influence.

$ spfquery --mfrom ***@tnpi.net --ip-address=`dig medusa.blackops.org +short`
pass
Received-SPF: pass (tnpi.net: Sender is authorized to use '***@tnpi.net' in 'mfrom' identity (mechanism 'include:lists._spf.tnpi.net' matched)) receiver=rmbp.local; identity=mailfrom; envelope-from="***@tnpi.net"; client-ip=208.69.40.157

Until we have a solution that lets DMARC mail securely transit email lists, our two legged DMARC table will wobble.

Matt

[Franck Martin]

Post by Matt Simerson
Absolutely.

+1

We always said don't move to p=reject till you have assessed the consequences, because receivers will not be complacent. If your email stream goes via a major forwarder and you can't live with the issue, don't do p=reject.

Post by Matt Simerson

Matt's message, as evaluated by Gmail, failed alignment, and was consequently marked as spam.

pass
Until we have a solution that lets DMARC mail securely transit email lists, our two legged DMARC table will wobble.

The same people will argue that the email eco-system is fine like this and should not change: https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F
I'm a little baffled by people making generalities, about me, personally, testing mailing lists (and especially most of the dmarc related lists) with p=reject, and people assuming a generality from this. As many other senders have found, the mailing list issue is marginal, for the senders with p=reject, for their email streams. Our users which were on mailing lists already used a private email address when we moved to p=reject. This is why also we were able to do it quickly. It was a non-issue from the start.

It is not expected for the receiver to change the way they receive emails with DMARC, but for the senders, only if they care their email to be delivered, and if they want users on a domain with p=reject to get these users to use a personal free email account to join mailing lists before making the change.

Thanks Matt for setting up the record straight, with your operational experience and data.

[Steve Atkins]

Post by Franck Martin
I'm a little baffled by people making generalities, about me, personally, testing mailing lists (and especially most of the dmarc related lists) with p=reject, and people assuming a generality from this.

It’s kind of a domain reputation issue. That you’re using an @linkedin.com email address for 1:1 email to mailing lists shows that linkedin.com are not an appropriate domain to use DMARC as they don’t have full control over how their domain is used for email (and that in turn leads to more pressure to special case delivery and ignore DMARC unless you know something more about the mail and so on). That you’re doing this on mailing lists that have a high visibility to DMARC folks means that the impact of that is *way* disproportionally large. :)

If you were to use a different domain for your testing of mailing list behaviour with DMARC (e.g. franckmartin.com or an entirely DMARC testing dedicated one) then the implication would be quite different.

Cheers,
Steve

[Franck Martin]

Post by Steve Atkins

Post by Franck Martin
I'm a little baffled by people making generalities, about me, personally, testing mailing lists (and especially most of the dmarc related lists) with p=reject, and people assuming a generality from this.

If you were to use a different domain for your testing of mailing list behaviour with DMARC (e.g. franckmartin.com or an entirely DMARC testing dedicated one) then the implication would be quite different.

non sequitur

[Matt Simerson]

Post by Steve Atkins

Post by Franck Martin
I'm a little baffled by people making generalities, about me, personally, testing mailing lists (and especially most of the dmarc related lists) with p=reject, and people assuming a generality from this.

And since "the impact is *way* disproportionally large" and still is barely an issue, doesn't that say something about how big a deal it really isn't?

Post by Steve Atkins
If you were to use a different domain for your testing of mailing list behaviour with DMARC (e.g. franckmartin.com or an entirely DMARC testing dedicated one) then the implication would be quite different.

I beg to differ. The DMARC implications are very different for messages from @linkedin.com or from @tnpi.net. What differs is how some receivers choose to react to those implications.

As lists go, for the DMARC implementer and/or tester, this list is a rich testing environment. There's a diversity of implementations and policies among the recipients, the list itself is a "worst case" in that it invalidates DKIM and does nothing to assist with SPF alignment. In that sense, the impact here of DMARC testing *is* disproportionally large. Even so, that large is still not very big.

Matt

[Murray S. Kucherawy]

Matt's message, as evaluated by Gmail, failed alignment, and was

consequently marked as spam.
Thanks to DMARC reports, the sender is quite aware. Of course I'd prefer
that this list didn't invalidate my DKIM signatures. I'd also prefer that
tnpi.net. But that's outside my ability to influence.

Have you reported that to Google?

pass
in 'mfrom' identity (mechanism 'include:lists._spf.tnpi.net' matched))
client-ip=208.69.40.157
Until we have a solution that lets DMARC mail securely transit email
lists, our two legged DMARC table will wobble.

Two things here:

1) The machine hosting the dmarc.org lists is in a position where upgrading
it will take quite a bit of effort, and that's needed before the MLM
software can be upgraded to a DMARC-aware version. I'm looking at
migrating the lists to a newer machine that will fix this problem. That
transition should be invisible when I get it done, but it simply hasn't
happened yet.

2) Since the ADSP days, the advice has been to have a separate domain or
subdomain for users versus transactional mail; the latter would be
DMARC-protected, while the former would not. I understand the
inconvenience this causes for the users, but I would also note that some
large Internet properties (Facebook, Google, PayPal and Yahoo off the top
of my head) have gone this route and they survived somehow.

-MSK

[Matt Simerson]

Post by Murray S. Kucherawy

Matt's message, as evaluated by Gmail, failed alignment, and was consequently marked as spam.

Have you reported that to Google?

Surely I have, and you likely have too, dozens of times over months and months, using this cool new email technology called DMARC. ;-)

I may have done so again by pointing out the issue on this list. But no, I didn't ever raise the issue with Google because back when I first noticed it I still:

a) wanted to fully understand the consequences of posting to lists with p=reject
b) having recipients on this list that validate SPF differently provides useful information
c) I haven't done enough debugging to determine exactly why it fails

Post by Murray S. Kucherawy

pass
Until we have a solution that lets DMARC mail securely transit email lists, our two legged DMARC table will wobble.

2) Since the ADSP days, the advice has been to have a separate domain or subdomain for users versus transactional mail; the latter would be DMARC-protected, while the former would not. I understand the inconvenience this causes for the users, but I would also note that some large Internet properties (Facebook, Google, PayPal and Yahoo off the top of my head) have gone this route and they survived somehow.

I, and others, have not gone that route and yet we too have survived. There are consequences to both approaches.

Matt

[Franck Martin]

Post by Matt Simerson

Post by Murray S. Kucherawy

Matt's message, as evaluated by Gmail, failed alignment, and was consequently marked as spam.

Have you reported that to Google?

Surely I have, and you likely have too, dozens of times over months and months, using this cool new email technology called DMARC. ;-)
a) wanted to fully understand the consequences of posting to lists with p=reject
b) having recipients on this list that validate SPF differently provides useful information
c) I haven't done enough debugging to determine exactly why it fails

Other list management systems than mailman have a different approach and send a last ping before unsubscribing someone due to bounces. Because this probe is sent from the list domain, it does not bounce and the member stay subscribed.

The other way to alleviate it is to raise the limit of days of bouncing before unsubscribing someone. As long as people with p=reject don't contribute much to a list, then it is all fine, you are not passing the thresholds where mailman thinks all the members at gmail, yahoo, hotmail,... are not there anymore due to too much bouncing.

http://www.gnu.org/software/mailman/mailman-admin/node25.html

I suspect setting bounce_you_are_disabled_warnings to >0 could help on this list.

[Murray S. Kucherawy]

Post by J. Gomez

Post by J. Gomez
Is it true that if you reject incoming email which fails DMARC

validation and whose sender's policy is REJECT, then you are in for a world
of hurt? Yes, it is true.
[...]
Applying p=reject on behalf of senders that ask for it barely ever hurts. If ever.

To be fair, there are cases (such as the MLM case, which you mentioned)
where it can cause some damage. Fortunately, those cases are well
understood and workarounds for them (outside the protocol, alas) exist.

Post by J. Gomez
I have the ability to easily apply locally crafted algorithms to determine
the probability of ham/spam for any given connection and/or message. I
disable SMTP rejections for mail plugins that frequently false positive
(DNSBL, SPF, DKIM, GeoIP, FCrDNS, header validity) and instead apply
heuristics scoring to plugin results. DMARC remains one of the few plugins
that I allow to reject connections on its own.

This is an important point. Popular free filtering programs like
Spamassassin can be easily altered to take DMARC results into account as
input to the overall filtering decision. It's equally easy to add
exemptions for certain sources. The notion that applying DMARC in
non-absolute ways is out of the reach of the masses seems plainly false to
me.

-MSK

[Dustin]

Perhaps one example of being wary of p=reject:
Matt's message, as evaluated by Gmail, failed alignment, and was
consequently marked as spam. In fact, every message in this thread has
failed DMARC with broken alignment. All messages were marked as spam unless
the sender set p=none or the sender was linkedin.com (presumably Google has
a special case for LinkedIn).

As others have noted, DMARC does not deal with forwarding (or 3rd party
senders) well. This is seems to be a big barrier towards the credibility of
p=reject and DMARC adoption in general (and is also the reason I use
p=none).

Dustin

Post by J. Gomez

Post by J. Gomez

Post by Tim Draegen
You guys are accumulating a bit of history of not really talking
about DMARC, but instead asserting random things that aren't true,
and then disappearing when asked to do some homework.

Is it true that if you reject incoming email which fails DMARC

validation and whose sender's policy is REJECT, then you are in for a world
of hurt? Yes, it is true.
True? I shovel male cow excrement upon your assertion.
Applying p=reject on behalf of senders that ask for it barely ever hurts. If ever.
I have been using DMARC validation in production for 10 months. When a
message results in a DMARC p=reject policy, I reject it. Period. I have
the ability to override DMARC policy, and I have the ability to exempt
connections from DMARC policy using a whitelist. I have used the whitelist
for exactly two IP addresses in 10 months, and in both cases it was for
testing commercial mail filtering appliances (trusted forwarders) in front
of my mail server.
I have the ability to easily apply locally crafted algorithms to determine
the probability of ham/spam for any given connection and/or message. I
disable SMTP rejections for mail plugins that frequently false positive
(DNSBL, SPF, DKIM, GeoIP, FCrDNS, header validity) and instead apply
heuristics scoring to plugin results. DMARC remains one of the few plugins
that I allow to reject connections on its own.
A DMARC policy of p=reject can be followed. Senders that publish such
policies [will soon] know that their messages that transit certain list
servers that insist upon breaking DKIM signatures will end up rejected. If
the sender is willing to live with that, the receiver should be too.
Matt

Post by J. Gomez
Therefore, DMARC'S p=reject is not something you can trust, nor follow.

Period. There is no clothing that puppet that is going to change this truth
about DMARC

Post by J. Gomez
You can feed a DMARC result of fail plus p=reject as score input into

some system to apply some locally crafted algorithms to determine the
probability of spamminess/phising, but then your are still not following
the stated POLICY of REJECT in the sender's DMARC. That is a truth. About
DMARC.

Post by J. Gomez
You can point to links which say "all is relative", "take it with a

grain of salt", etc. That's fine. That, however, does not change the truth
that you cannot trust nor follow DMARC's POLICY of REJECT. You, at most,
can take it into account as a score/weight to do further local processing -
OK, but you are then not REJECTing as per the sender's DMARC policy.
Undeniable truth, that.

Post by J. Gomez
It is the DMARC specification that chose to call it "policy", not

"recommendation". And policy is a policy, not a suggestion. Twisting words
to fit ex-post facto scenarios/realities is not funny.

Post by J. Gomez
Perhaps you can spend your whole working day, day after day, fine tuning

your local DMARC processing secret-sauce. Good for you. Other people do not
have that luxury.

Post by J. Gomez
Regards,
J.Gomez
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well

terms (http://www.dmarc.org/note_well.html)
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well
terms (http://www.dmarc.org/note_well.html)

[Franck Martin]

Matt's message, as evaluated by Gmail, failed alignment, and was consequently marked as spam. In fact, every message in this thread has failed DMARC with broken alignment. All messages were marked as spam unless the sender set p=none or the sender was linkedin.com (presumably Google has a special case for LinkedIn).
As others have noted, DMARC does not deal with forwarding (or 3rd party senders) well. This is seems to be a big barrier towards the credibility of p=reject and DMARC adoption in general (and is also the reason I use p=none).

No, it is not. Unless you want everyone to do DMARC p=reject.

First DMARC deals very well with forwarding, if the message remains unaltered during forwarding, which happens in many cases: forwarding an email between gmail and yahoo, will keep DKIM valid, if not mistaken.

A lot of senders that moved to p=reject have found that forwarders that break DKIM, are for them, and I repeat for them, not an issue in comparison to the spoofing problem.

So DMARC p=reject is not for all, and if you want to use it, you need to change all your mail streams, which for some is not a simple task and only motivated if there is something to gain.

[Roland Turner]

Post by J. Gomez

Post by Tim Draegen
You guys are accumulating a bit of history of not really talking
about DMARC, but instead asserting random things that aren't true,
and then disappearing when asked to do some homework.

Is it true that if you reject incoming email which fails DMARC validation and whose sender's policy is REJECT, then you are in for a world of hurt? Yes, it is true.

No, it's false:

* It's hyperbolic; there is likely to be some difficulty, not likely
to be "a world of hurt".
* Whether or not following the sender's policy for any specific DMARC
failure is going to create one of those difficulties will vary
depending upon a number of independent variables, most notably
including whether the Domain Owner has their ducks in a row and
whether the message has been forwarded in a way that breaks DKIM.

Post by J. Gomez
Therefore, DMARC'S p=reject is not something you can trust, nor follow. Period. There is no clothing that puppet that is going to change this truth about DMARC

Also false.

You are attempting to characterise DMARC use by a receiver as an
all-or-nothing proposition and/or as something which receivers would
benefit from following blindly. This is simply not true. It's not what
DMARC was designed to do. It's not what any sensible receiver would try
to do.

You are viewing this from the same unworkable viewpoint which led to the
failures of SPF -all, DomainKeys o=- and ADSP dkim=discardable. DMARC
has succeeded in large part because it has left this unworkable
viewpoint behind. The sooner you let go of the errors of the past, the
sooner you'll be able to make good use of DMARC.

Post by J. Gomez
You can feed a DMARC result of fail plus p=reject as score input into some system to apply some locally crafted algorithms to determine the probability of spamminess/phising,

This is not a good idea. For a given 5322.From-domain and
source-IP-address combination, the DMARC result should either be
followed or ignored. Probabilistic approaches are a very poor fit.

...

Post by J. Gomez
It is the DMARC specification that chose to call it "policy", not "recommendation". And policy is a policy, not a suggestion. Twisting words to fit ex-post facto scenarios/realities is not funny.

OK, this is perhaps the core of your misunderstanding. That a Domain
Owner expresses a policy which a receiver elects to ignore does not mean
that it's not a policy, merely that it's not binding upon the receiver.
One party's policy _*is*_ the other party's recommendation, suggestion
or request. This is not a contradiction, nor is it ex post facto
twisting; this is the plain English meaning of the word.

If the meaning of the word policy is all that's been bothering you, then
perhaps you are now in a position to reconsider your view?

- Roland

[J. Gomez]

---- Original Message from: Roland Turner

Post by Roland Turner
You are attempting to characterise DMARC use by a receiver as an
all-or-nothing proposition and/or as something which receivers would
benefit from following blindly. This is simply not true. It's not
what DMARC was designed to do. It's not what any sensible receiver
would try to do.
You are viewing this from the same unworkable viewpoint which led to
the failures of SPF -all, DomainKeys o=- and ADSP dkim=discardable.
DMARC has succeeded in large part because it has left this unworkable
viewpoint behind. The sooner you let go of the errors of the past,
the sooner you'll be able to make good use of DMARC.

We probably inhabit different universes. In mine, SPF -all "just works" and, most importantly, it allows the receiver to outsource onto the sender 100% of the blame arising from any non-deliveries because of SPF -all failures; also, in my universe DMARC has not "succeeded" -- not yet, at least.

For DMARC to be a viable option for receivers, it has to provide them with a non-refutable answer/position for the cases when mail is not delivered because of DMARC failures. If receivers are expected to build a custom, fine-tuned, on-going maintenance-heavy local-only system to deal with DMARC failure cases, because receivers cannot just outsource onto senders the blame for DMARC failure cases, then most receivers WILL NOT IMPLEMENT DMARC. My guess is many receivers will not implement DMARC after having burned to much time and support costs dealing with DMARC failure cases.

Post by Roland Turner
OK, this is perhaps the core of your misunderstanding. That a Domain
Owner expresses a policy which a receiver elects to ignore does not
mean that it's not a policy, merely that it's not binding upon the
receiver. One party's policy is the other party's recommendation,
suggestion or request.

One party's policy published for the consumption of the receivers, is a policy expected to be treated as policy by the receivers, otherwise it would be the first party's private-policy and not the first party's published-policy. If what I publish as policy is to be regarded as a song, then why do I bother publishing a policy instead of a song?

Post by Roland Turner
This is not a contradiction, nor is it ex post
facto twisting; this is the plain English meaning of the word.

Policy is policy. That someone opts to not follow it, makes it an ignored policy, not a non-policy. Therefore, DMARC's policy of p=reject is best to be ignored. Or, in other words, there is not such a thing as a workable policy of REJECT in DMARC.

Regards,

J.Gomez

[Roland Turner]

Post by J. Gomez
We probably inhabit different universes.

This is conceivable :-)

Post by J. Gomez
In mine, SPF -all "just works" and, most importantly, it allows the
receiver to outsource onto the sender 100% of the blame arising from
any non-deliveries because of SPF -all failures; also, in my universe
DMARC has not "succeeded" -- not yet, at least.

So:

* The test of SPF -all's effectiveness is not whether it can be turned
on without doing damage but whether it contributes materially to
preventing spoofing. It doesn't; spoofers can and do trivially pass SPF.
* Few receivers have the luxury of being able to blame others for
disrupting legitimate email flows. If you are one of those who can
get away with this, then by all means implement DMARC as-is. If it
suddenly turns out that your users

Post by J. Gomez
For DMARC to be a viable option for receivers, it has to provide them
with a non-refutable answer/position for the cases when mail is not
delivered because of DMARC failures. If receivers are expected to
build a custom, fine-tuned, on-going maintenance-heavy local-only
system to deal with DMARC failure cases, because receivers cannot just
outsource onto senders the blame for DMARC failure cases, then most
receivers WILL NOT IMPLEMENT DMARC. My guess is many receivers will
not implement DMARC after having burned to much time and support costs
dealing with DMARC failure cases.

Post by Roland Turner
OK, this is perhaps the core of your misunderstanding. That a Domain
Owner expresses a policy which a receiver elects to ignore does not
mean that it's not a policy, merely that it's not binding upon the
receiver. One party's policy is the other party's recommendation,
suggestion or request.

One party's policy published for the consumption of the receivers, is a policy expected to be treated as policy by the receivers, otherwise it would be the first party's private-policy and not the first party's published-policy. If what I publish as policy is to be regarded as a song, then why do I bother publishing a policy instead of a song?

Post by Roland Turner
This is not a contradiction, nor is it ex post
facto twisting; this is the plain English meaning of the word.

Policy is policy. That someone opts to not follow it, makes it an ignored policy, not a non-policy. Therefore, DMARC's policy of p=reject is best to be ignored. Or, in other words, there is not such a thing as a workable policy of REJECT in DMARC.
Regards,
J.Gomez
_______________________________________________
dmarc-discuss mailing list
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[Murray S. Kucherawy]

Post by J. Gomez
We probably inhabit different universes. In mine, SPF -all "just works"
and, most importantly, it allows the receiver to outsource onto the sender
100% of the blame arising from any non-deliveries because of SPF -all
failures; also, in my universe DMARC has not "succeeded" -- not yet, at
least.

Based on my experience, you do indeed live in a different universe. I have
no first hand exposure to any installation that respects SPF "-all" above
all others. Quite literally every place I have ever worked or otherwise
had an inbox has used SPF's result as part of a larger message evaluation
system because false negatives and spoofs are too much of a concern.

I fully understand that there exist places where acting on an SPF failure
with "-all" by rejecting the message "just works". I am not saying they
don't exist. I am saying that they appear not to be common.

For DMARC to be a viable option for receivers, it has to provide them with

Post by J. Gomez
a non-refutable answer/position for the cases when mail is not delivered
because of DMARC failures. If receivers are expected to build a custom,
fine-tuned, on-going maintenance-heavy local-only system to deal with DMARC
failure cases, because receivers cannot just outsource onto senders the
blame for DMARC failure cases, then most receivers WILL NOT IMPLEMENT
DMARC. My guess is many receivers will not implement DMARC after having
burned to much time and support costs dealing with DMARC failure cases.

Your shouted prediction here is countered by fact, at least in terms of
number of mailboxes covered and ample anecdotal evidence.

As has been repeatedly stated, DMARC is not for everyone. If it doesn't
handle your use case or the exception handling you will need for your
installation is too expensive, then don't use it.

On the other hand, the Internet is a fertile ground for innovation, so
perhaps there's room for someone to devise a system whereby the exceptions
can be shared among interested parties so that they can spread the costs of
identifying and handling them.

For the sake of encouraging this thread to actually be constructive, I
invite you to propose any text changes that you believe will actually
compel receivers to honor the DMARC result irrespective of other concerns.
If you can succeed where all others before you have failed, I can guarantee
you'll have a new fan club.

Post by J. Gomez
One party's policy published for the consumption of the receivers, is a
policy expected to be treated as policy by the receivers, otherwise it
would be the first party's private-policy and not the first party's
published-policy. If what I publish as policy is to be regarded as a song,
then why do I bother publishing a policy instead of a song?

What gives you, as a sender, domain over how receivers will behave? Those
are their resources and their users, not yours. They are the ones that get
the support calls when your actions (or inactions) cause some kind of
negative user experience. They incur the costs of your actions (or
inactions). Expecting them to simply do what you command is ridiculous,
and they deserve what they get if they do so.

Post by J. Gomez

Post by Roland Turner
This is not a contradiction, nor is it ex post
facto twisting; this is the plain English meaning of the word.

Policy is policy. That someone opts to not follow it, makes it an ignored
policy, not a non-policy. Therefore, DMARC's policy of p=reject is best to
be ignored. Or, in other words, there is not such a thing as a workable
policy of REJECT in DMARC.

This is still flatly incorrect. Simply repeating it doesn't make it true.

I asked you before if the "P" in "SPF" (which stands for "policy", I would
remind you) causes you similar friction. Does it? Do you have another
word you'd like to see in its place, at least in the DMARC documents?

More generally, do you have alternative text to propose for the current
DMARC base draft that talks about the "policy" as, effectively, a request
to receivers? The base draft does go to some length to explain this
already.

More generally still, I would really love to see some constructive feedback
here. Otherwise, I believe this reduces to little more than skeptical
ranting, and we should move forward.

-MSK

[J. Gomez]

Post by Murray S. Kucherawy

Post by J. Gomez
We probably inhabit different universes. In mine, SPF -all "just
works" and, most importantly, it allows the receiver to outsource
onto the sender 100% of the blame arising from any non-deliveries
because of SPF -all failures; also, in my universe DMARC has not
"succeeded" -- not yet, at least.

Based on my experience, you do indeed live in a different universe.
I have no first hand exposure to any installation that respects SPF
"-all" above all others. Quite literally every place I have ever
worked or otherwise had an inbox has used SPF's result as part of a
larger message evaluation system because false negatives and spoofs
are too much of a concern.
I fully understand that there exist places where acting on an SPF
failure with "-all" by rejecting the message "just works". I am not
saying they don't exist. I am saying that they appear not to be
common.

I plain reject on SPF -all, and my clients are fine with it, in several different installations. Exceptions are added to a whitelist on a case by case basis, and only if the sender is some automatic system whose administrator is not easily reachable. Otherwise, the sender is told they are spoofing the domain against the domain owner's policy, and the case is closed. It works, because it's the sender's fault, and because it is plain easy to see it and to check it, AND BECAUSE IT IS PLAIN EASY FOR THE SENDER TO FIX IT. So far, my clients are happy. I also reject on SPF softfail for some heavily spoofed domains -- and, again, so far my clients are happy with their spam free inboxes.

The case will not be so easy for DMARC's p=reject false positives. It is going to be hard for the sender to fix them, because they are going to keep publishing p=reject AND having users subscribing to mailing lists (so is human nature -- senders are not going to go through the all trouble of learning about DMARC, setting it up, just to end up not using p=reject to "protect" their "precious" email domain/brand). Yes, I know your answer: that the receiver has to build a custom, fine-tuned, on-going maintenance-heavy local-only system to deal with those DMARC failure cases, as the DMARC standard so aptly suggests. Therefore, the conclusion is clear: DMARC has NOT a workable policy of reject for receivers to implement.

But I guess if someone is hired full time to deal with the support tickets for DMARC failure cases, then his definition of "workable" would be different.

Post by Murray S. Kucherawy

Post by J. Gomez
For DMARC to be a viable option for receivers, it has to provide them
with a non-refutable answer/position for the cases when mail is not
delivered because of DMARC failures. If receivers are expected to
build a custom, fine-tuned, on-going maintenance-heavy local-only
system to deal with DMARC failure cases, because receivers cannot
just outsource onto senders the blame for DMARC failure cases, then
most receivers WILL NOT IMPLEMENT DMARC. My guess is many receivers
will not implement DMARC after having burned to much time and support
costs dealing with DMARC failure cases.

Your shouted prediction here is countered by fact, at least in terms
of number of mailboxes covered and ample anecdotal evidence.

My stated prediction is exactly correct, at least in terms of the number of mailbox providers currently covered by DMARC.

Post by Murray S. Kucherawy
As has been repeatedly stated, DMARC is not for everyone. If it
doesn't handle your use case or the exception handling you will need
for your installation is too expensive, then don't use it.

I won't, as a receiver. I will, as a sender, with p=none and just to get feedback reports on my email streams.

Post by Murray S. Kucherawy
On the other hand, the Internet is a fertile ground for innovation,
so perhaps there's room for someone to devise a system whereby the
exceptions can be shared among interested parties so that they can
spread the costs of identifying and handling them.

That could work: a Spamhaus.org-like service for sharing known-good DMARC whitelisting of DMARC p=reject failure cases, based on the sending domain or, perhaps better, on known-good mailing-lists/forwarders.

Post by Murray S. Kucherawy
For the sake of encouraging this thread to actually be constructive,
I invite you to propose any text changes that you believe will
actually compel receivers to honor the DMARC result irrespective of
other concerns. If you can succeed where all others before you have
failed, I can guarantee you'll have a new fan club.

I already did. It was summarily dismissed, though. So I tried, I did not just complained.

http://www.ietf.org/mail-archive/web/dmarc/current/msg00167.html

Post by Murray S. Kucherawy

Post by J. Gomez
One party's policy published for the consumption of the receivers, is
a policy expected to be treated as policy by the receivers, otherwise
it would be the first party's private-policy and not the first
party's published-policy. If what I publish as policy is to be
regarded as a song, then why do I bother publishing a policy instead
of a song?

What gives you, as a sender, domain over how receivers will behave?
Those are their resources and their users, not yours. They are the
ones that get the support calls when your actions (or inactions)
cause some kind of negative user experience. They incur the costs of
your actions (or inactions). Expecting them to simply do what you
command is ridiculous, and they deserve what they get if they do so.

Sorry, but it IS reasonable to expect that someone who goes through the effort of using his resources and time to find out about your published policy, will then follow it -- specially when the onerous part is the first one, finding about the policy, and not the second one, following it (ie., just dumping failures on p=reject). If the receiver was not interested on the sender's policy, why did he bothered to check it at all? Was he bored? Was he just doing field research and collating statistics? What is going on here? --> What is going on here is the reality that DMARC's reject policy is UNRELIABLE, and therefore unworkable.(*)

(*) Unless, of course, the receiver wants to build a custom, fine-tuned, on-going maintenance-heavy local-only system to deal with DMARC failure cases.

Post by Murray S. Kucherawy

Post by J. Gomez
Policy is policy. That someone opts to not follow it, makes it an
ignored policy, not a non-policy. Therefore, DMARC's policy of
p=reject is best to be ignored. Or, in other words, there is not such
a thing as a workable policy of REJECT in DMARC.

This is still flatly incorrect. Simply repeating it doesn't make it true.

OK then, policy is not policy. You are right.

Post by Murray S. Kucherawy
More generally still, I would really love to see some constructive
feedback here.

I am sorry you do not like my feedback. It must is destructive.

Regards,

J.Gomez


PS: I would love it if your posts to the list would keep the proper quotation marks in their plain-text alternative version, so that quoting them would not longer be an exercise in acrobatics.

[Roland Turner]

Post by J. Gomez
I plain reject on SPF -all, and my clients are fine with it,

Excellent! You have found a tool that works for you, you should
definitely keep using it.

Does it make sense to you that others may find other tools useful
(including ones that you don't) and therefore keep using them despite
their not being useful to you? That a tool is not [currently] useful to
you doesn't make it not useful to others.

Post by J. Gomez
senders are not going to go through the all trouble of learning about
DMARC, setting it up, just to end up not using p=reject to "protect"
their "precious" email domain/brand

It is interesting that you quote the words protect and precious, it
makes it look as though you don't view what heavily spoofed domain
owners are using DMARC for as protective and/or that you don't view
their domains - or their customers' money in the case of payment service
providers' customers' whom criminals frequently target - as valuable. Is
this what you intended?

Post by J. Gomez
My stated prediction is exactly correct, at least in terms of the
number of mailbox providers currently covered by DMARC.

DMARC's success is measured by number of mailboxes protected, not by
number of mailbox providers.

Post by J. Gomez
That could work: a Spamhaus.org-like service for sharing known-good DMARC whitelisting of DMARC p=reject failure cases, based on the sending domain or, perhaps better, on known-good mailing-lists/forwarders.

I suspect that this will happen in the not-too-distant future.

In this respect, the situation with DMARC receivers mapping competent
Domain Owners and reliable receivers is comparable to, although probably
easier than, SMTP receivers mapping abusive senders. Doing so in both
cases is clearly beyond the resources of a small receiver, but this does
not mean that either specification is useless generally, or even useless
for small receivers, only that some help on assessing the behaviour of
others is a necessary precondition for small installations.

Post by J. Gomez
I already did. It was summarily dismissed, though. So I tried, I did not just complained.
http://www.ietf.org/mail-archive/web/dmarc/current/msg00167.html

You weren't summarily dismissed. Gaping holes in your proposal were
pointed out, in detail, and you didn't resolve them.

Post by J. Gomez
Sorry, but it IS reasonable to expect that someone who goes through
the effort of using his resources and time to find out about your
published policy, will then follow it

This is false. As with just about everything else that receivers do to
protect themselves, either directly or with the aid of others, gathering
data is performed to support a decision, not to delegate that decision
to senders (the whole point of receiver-side security systems being to
disrupt the activities of a class of hard-to-spot sender).

- Roland

[Murray S. Kucherawy]

Post by J. Gomez
I plain reject on SPF -all, and my clients are fine with it, in several
different installations. Exceptions are added to a whitelist on a case by
case basis, and only if the sender is some automatic system whose
administrator is not easily reachable.

So having an exception system for SPF is acceptable and SPF is useful to
you. At the same time, the thought of doing so for DMARC makes the entire
concept undeployable. Is that correct?

It's fine that rejecting on SPF -all works for you. It doesn't work for a
lot of other operators. Your situation does not generalize to the deployed
Internet.

Otherwise, the sender is told they are spoofing the domain against the

Post by J. Gomez
domain owner's policy, and the case is closed. It works, because it's the
sender's fault, and because it is plain easy to see it and to check it, AND
BECAUSE IT IS PLAIN EASY FOR THE SENDER TO FIX IT. So far, my clients are
happy. I also reject on SPF softfail for some heavily spoofed domains --
and, again, so far my clients are happy with their spam free inboxes.

"For some heavily spoofed domains" means you're maintaining an exception
list for that case as well, unless you've found a published list of those
someplace.

Post by J. Gomez
The case will not be so easy for DMARC's p=reject false positives. It is
going to be hard for the sender to fix them, because they are going to keep
publishing p=reject AND having users subscribing to mailing lists (so is
human nature -- senders are not going to go through the all trouble of
learning about DMARC, setting it up, just to end up not using p=reject to
that the receiver has to build a custom, fine-tuned, on-going
maintenance-heavy local-only system to deal with those DMARC failure cases,
as the DMARC standard so aptly suggests. Therefore, the conclusion is
clear: DMARC has NOT a workable policy of reject for receivers to implement.

That is not the only solution that has been presented here.

Post by J. Gomez

Post by Murray S. Kucherawy

Post by J. Gomez
For DMARC to be a viable option for receivers, it has to provide them
with a non-refutable answer/position for the cases when mail is not
delivered because of DMARC failures. If receivers are expected to
build a custom, fine-tuned, on-going maintenance-heavy local-only
system to deal with DMARC failure cases, because receivers cannot
just outsource onto senders the blame for DMARC failure cases, then
most receivers WILL NOT IMPLEMENT DMARC. My guess is many receivers
will not implement DMARC after having burned to much time and support
costs dealing with DMARC failure cases.

Your shouted prediction here is countered by fact, at least in terms
of number of mailboxes covered and ample anecdotal evidence.

My stated prediction is exactly correct, at least in terms of the number
of mailbox providers currently covered by DMARC.

Please explain why that is a more important consideration than the number
of users being protected.

Post by J. Gomez

Post by Murray S. Kucherawy
As has been repeatedly stated, DMARC is not for everyone. If it
doesn't handle your use case or the exception handling you will need
for your installation is too expensive, then don't use it.

I won't, as a receiver. I will, as a sender, with p=none and just to get
feedback reports on my email streams.

Excellent.

Post by J. Gomez

Post by Murray S. Kucherawy
On the other hand, the Internet is a fertile ground for innovation,
so perhaps there's room for someone to devise a system whereby the
exceptions can be shared among interested parties so that they can
spread the costs of identifying and handling them.

That could work: a Spamhaus.org-like service for sharing known-good DMARC
whitelisting of DMARC p=reject failure cases, based on the sending domain
or, perhaps better, on known-good mailing-lists/forwarders.

Precisely. And the publication and query methods already exist.

Post by J. Gomez

Post by Murray S. Kucherawy
For the sake of encouraging this thread to actually be constructive,
I invite you to propose any text changes that you believe will
actually compel receivers to honor the DMARC result irrespective of
other concerns. If you can succeed where all others before you have
failed, I can guarantee you'll have a new fan club.

I already did. It was summarily dismissed, though. So I tried, I did not just complained.
http://www.ietf.org/mail-archive/web/dmarc/current/msg00167.html

Criticism of your proposal was presented (and linked from that page) by
several people that you were not able or willing to refute. Labeling that
as "summarily dismissed" is plainly invalid.

You even admitted that one obvious criticism is that your proposal is
ultimately useless. Part of your counter-argument was that your proposal
merely conveys additional information from the sender to the receiver, and
the latter is free to consume it as he wishes or disregard it altogether.
This seems awfully familiar to things we've been saying, yet if we say
them, they are bogus to you.

Post by J. Gomez

Post by Murray S. Kucherawy
What gives you, as a sender, domain over how receivers will behave?
Those are their resources and their users, not yours. They are the
ones that get the support calls when your actions (or inactions)
cause some kind of negative user experience. They incur the costs of
your actions (or inactions). Expecting them to simply do what you
command is ridiculous, and they deserve what they get if they do so.

Sorry, but it IS reasonable to expect that someone who goes through the
effort of using his resources and time to find out about your published
policy, will then follow it -- specially when the onerous part is the first
one, finding about the policy, and not the second one, following it (ie.,
just dumping failures on p=reject). If the receiver was not interested on
the sender's policy, why did he bothered to check it at all? Was he bored?
Was he just doing field research and collating statistics? What is going on
here? --> What is going on here is the reality that DMARC's reject policy
is UNRELIABLE, and therefore unworkable.(*)

Your "field research" quip is closest to reality.

Your conclusion that DMARC's reject policy is unreliable suggests you only
consider a sender policy to be reliable if all receivers are assured (or
perhaps are compelled) to obey it. By that logic, you must also admit that
SPF's "-all" is unreliable, because the majority of receivers out there
today don't honor it, largely for the same reasons that DMARC's reject
policy is not blindly followed.

Post by J. Gomez
(*) Unless, of course, the receiver wants to build a custom, fine-tuned,
on-going maintenance-heavy local-only system to deal with DMARC failure
cases.

Sounds like you have one for SPF already. I don't understand why it's
different for DMARC.

Post by J. Gomez

Post by Murray S. Kucherawy

Post by J. Gomez
Policy is policy. That someone opts to not follow it, makes it an
ignored policy, not a non-policy. Therefore, DMARC's policy of
p=reject is best to be ignored. Or, in other words, there is not such
a thing as a workable policy of REJECT in DMARC.

This is still flatly incorrect. Simply repeating it doesn't make it true.

OK then, policy is not policy. You are right.

I have invited you on more than one occasion to explain why the "P" in SPF
is okay with you given it is rarely directly enforced, or to offer
alternative terminology or text for the DMARC base specification to resolve
this dissonance you have around the word "policy". The latter would
certainly be constructive. You have done neither.

Post by J. Gomez

Post by Murray S. Kucherawy
More generally still, I would really love to see some constructive
feedback here.

I am sorry you do not like my feedback. It must is destructive.

Similarly, I'm sorry that DMARC will not work for you. I'm also sorry that
your aforementioned suggestion did not survive some basic criticisms (one
of which you yourself offered, in fact). That doesn't mean DMARC won't
work for anyone, or that it is harmful, or that this work should not
proceed. However, I would hope you can appreciate that "This won't work
for me, therefore it's bad" is breathtakingly faulty logic.

Post by J. Gomez
PS: I would love it if your posts to the list would keep the proper
quotation marks in their plain-text alternative version, so that quoting
them would not longer be an exercise in acrobatics.

You are welcome to open a bug report with Gmail.

Given that this thread isn't going in any sort of constructive direction
anymore, I recommend it be allowed to die.

-MSK

[J. Gomez]

Post by Murray S. Kucherawy
So having an exception system for SPF is acceptable and SPF is useful
to you. At the same time, the thought of doing so for DMARC makes
the entire concept undeployable. Is that correct?

DMARC has a prominent failure case with mailing lists; also, such failure cases are not readily obvious to prospect would-be DMARC adopters as Senders. SPF does not have those problems. Therefore, DMARC is much more hairy to properly implement as a receiver that SPF. If you don't want to acknowledge that, but prefer to misrepresent my position and to posit it as ridiculous or inconsistent, then I feel very much dismayed.

Post by Murray S. Kucherawy

Post by J. Gomez

Post by Murray S. Kucherawy

Post by J. Gomez
For DMARC to be a viable option for receivers, it has to provide
them with a non-refutable answer/position for the cases when mail is
not delivered because of DMARC failures. If receivers are
expected to build a custom, fine-tuned, on-going
maintenance-heavy local-only system to deal with DMARC failure
cases, because receivers cannot just outsource onto senders the
blame for DMARC failure cases, then most receivers WILL NOT
IMPLEMENT DMARC. My guess is many receivers will not implement
DMARC after having burned to much time and support costs dealing
with DMARC failure cases.

Your shouted prediction here is countered by fact, at least in terms
of number of mailboxes covered and ample anecdotal evidence.

My stated prediction is exactly correct, at least in terms of the
number of mailbox providers currently covered by DMARC.

Please explain why that is a more important consideration than the
number of users being protected.

Please, explain why the internally-agreed-upon practices of the oligopolistic big four mailbox providers need to be sanctioned as an Internet-wide official standard disregarding the operational problems such an standard in its current formulation would bring to the smaller players in the email arena.

Post by Murray S. Kucherawy

Post by J. Gomez

Post by Murray S. Kucherawy
For the sake of encouraging this thread to actually be constructive,
I invite you to propose any text changes that you believe will
actually compel receivers to honor the DMARC result irrespective of
other concerns. If you can succeed where all others before you have
failed, I can guarantee you'll have a new fan club.

I already did. It was summarily dismissed, though. So I tried, I did
not just complained.
http://www.ietf.org/mail-archive/web/dmarc/current/msg00167.html

Criticism of your proposal was presented (and linked from that page)
by several people that you were not able or willing to refute.

I don't have time to "defend" it if the usefulness of my proposal happens to not be directly obvious to other email players. I also don't have a lobby group to defend it for me.

But I will try just again, succinctly: the "l=" tag would allow Senders who implement p=reject and then discover false positives in the email they send, to declare a posteriori (after they discover the trouble) to the Receivers that their users do indeed use mailing lists, so that the Receivers could bring that additional data point into their local "secret-sauce" DMARC evaluation system. You, on the other hand, think that in that case the Sender should just not use p=reject, therefore you don't see the need for the "l=" tag. Well, I guess then you also think the world is a Cartesian universe and its inhabitants are Kantian people. It must be nice to live in such a clear cut world. Also, I guess nobody at linkedin.com with it's nice DMARC policy of p=reject ever participates with such an address in mailing lists, right?

Post by Murray S. Kucherawy
Your conclusion that DMARC's reject policy is unreliable suggests you
only consider a sender policy to be reliable if all receivers are
assured (or perhaps are compelled) to obey it. By that logic, you
must also admit that SPF's "-all" is unreliable, because the majority
of receivers out there today don't honor it, largely for the same
reasons that DMARC's reject policy is not blindly followed.

DMARC's reject policy is unreliable because it has obvious failure cases. By that same logic, SPF -all does not have those failure cases, so it is much more reliable. I don't know how do I have to say that to be understood, what part of that you don't understand?

Post by Murray S. Kucherawy
(*) Unless, of course, the receiver wants to build a custom,
fine-tuned, on-going maintenance-heavy local-only system to deal with
DMARC failure cases.
Sounds like you have one for SPF already. I don't understand why
it's different for DMARC.

Sigh. I think I give up.

Post by Murray S. Kucherawy

Post by J. Gomez
PS: I would love it if your posts to the list would keep the proper
quotation marks in their plain-text alternative version, so that
quoting them would not longer be an exercise in acrobatics.

You are welcome to open a bug report with Gmail.

If you think it would be normal for a third party to open a bug report with Gmail about a problem a Gmail user has with a Gmail product, then... OK, yeah, you are right.

Regards,

J.Gomez

[Murray S. Kucherawy]

Post by J. Gomez
DMARC has a prominent failure case with mailing lists; also, such failure
cases are not readily obvious to prospect would-be DMARC adopters as
Senders. SPF does not have those problems.

That's false. SPF and DKIM both have problems with mailing lists and/or
forwarding, depending on how the relevant software is configured to
behave. These issues have existed for many years and are well documented.
DMARC, which is in effect a layer atop those, is not introducing anything
new here.

Therefore, DMARC is much more hairy to properly implement as a receiver

Post by J. Gomez
that SPF. If you don't want to acknowledge that, but prefer to misrepresent
my position and to posit it as ridiculous or inconsistent, then I feel very
much dismayed.

Your premise is false, thus your conclusion is unsupported. That has
nothing at all to do with what I do or do not want to acknowledge; your
facts are simply in error. I don't believe I'm misrepresenting your
position, but I am trying to reveal flaws in your arguments from the
perspective of someone reading them (and who has been down this road
before). If I have misunderstood or you believe my facts are wrong, you
are certainly welcome to try to set us all straight (preferably with
evidence rather than opinion). Thus far, however, all I can see are
repeated claims that either don't appear to be backed by reality or are
contradicted by other things you've said.

For the sake of being complete: The equivalent to your "l=" idea was
proposed during the development of several of DMARC's antecedents,
including DKIM and ADSP and probably others. The counter-argument has
always been the same: Such a flag, if set, weakens the meaning of a
"reject" policy to the point of absurdity: An attacker simply makes any
post look like it came in via a list (for which there is no deterministic
identification algorithm in the first place), and the mail won't certainly
be rejected as it ought to be. One might argue that "p=reject l=true" is
equivalent to "p=quarantine", which we already have. Either way, this is
plainly a showstopper for your suggestion. I don't see anything in your
original suggestion or this re-statement that defeats this
counter-argument. This is why several people, not just me, challenged your
suggestion when you made it.

Post by J. Gomez
Please explain why that is a more important consideration than the

Post by Murray S. Kucherawy
number of users being protected.

Please, explain why the internally-agreed-upon practices of the
oligopolistic big four mailbox providers need to be sanctioned as an
Internet-wide official standard disregarding the operational problems such
an standard in its current formulation would bring to the smaller players
in the email arena.

There are several fallacies in here as well, not to mention a wandering off
into the irrelevant. In fact there appear to be so many logical
inconsistencies and previously refuted points in your claims and
conclusions that, as you so aptly put it, I give up.

-MSK

[Benny Pedersen]

Spf is transperant on maillists
Sender-id is not
Dkim is transperant on maillist if no signed headers is changed or body is not changed
Dmarc works if all of the above passes even if dmarc policy say reject

Stop being ignorants

[Murray S. Kucherawy]

Post by Benny Pedersen
Spf is transperant on maillists

SPF is not transparent for plain forwarding, nor for lists that don't
rewrite the envelope. Many do, some don't.

Take a minute to read Section 9 of RFC4408, or Section 10 of the RFC that
will soon replace it, for more information.

Stop being ignorants
Decorum, please.

-MSK

[J. Gomez]

Post by Murray S. Kucherawy

Post by Benny Pedersen
Spf is transperant on maillists

SPF is not transparent for plain forwarding, nor for lists that don't
rewrite the envelope. Many do, some don't.

SPF is transparent on mailing lists. Cases where mailing lists don't take ownership of the SMTP MAIL-FROM return-path, are extinct.

But perhaps a total of ONE exception may exist in the whole world, so that you could prove your point. And if it could not be found, I volunteer to set it up myself, lest your point would end up unproven.

Regards,
J.Gomez

[Roland Turner]

Post by J. Gomez
Please, explain why the internally-agreed-upon practices of the oligopolistic big four mailbox providers need to be sanctioned as an Internet-wide official standard disregarding the operational problems such an standard in its current formulation would bring to the smaller players in the email arena.

Setting aside the difficulties with this sentence that Murray has
already identified, I wonder whether this sentence points to part of
your extraordinary enmity towards DMARC.

Your sentence attempts to portray DMARC standardisation as something
which will impose operational problems on "smaller players". Do you imagine:

* that the standardisation of DMARC will by itself somehow create
operational problems for smaller organisations which don't implement it?
* that organisations, small or not, will choose to implement it
despite the cost of implementation and operation exceeding the
benefits thereby obtained?
* that they'll somehow be compelled to implement it and therefore have
to shoulder a cost that shouldn't be theirs?
* something else?

What is it about DMARC in particular, in contrast to _*ALL*_ of the
other protocols and tools that have ever been developed, that makes you
unwilling to simply view it as a tool for you (and others) to implement
if it's helpful or to disregard if it's not? In particular, per the
wording of your sentence, is there some specific problem in your mind
with a protocol developed by a few large organisations in a closed
environment being subsequently made public, and in particular with
having done so after a decade of open development had abjectly failed to
disrupt the use of spoofing by criminals?

Your choice of words makes it sound as though you view DMARC as some
sort of obligation imposed from above. Not only does it not impose an
obligation of any kind on anyone, it hands us a solution to a problem
that we've butted heads over for a decade. Perhaps you are not inclined
to bow an scrape while expressing your gratitude (neither am I), but if
it's the large corporate origin of DMARC that's motivating your
response, then perhaps your response is simply misplaced.

- Roland

[Rolf E. Sonneveld]

Post by J. Gomez
---- Original Message from: Roland Turner

Post by Roland Turner
You are attempting to characterise DMARC use by a receiver as an
all-or-nothing proposition and/or as something which receivers would
benefit from following blindly. This is simply not true. It's not
what DMARC was designed to do. It's not what any sensible receiver
would try to do.
You are viewing this from the same unworkable viewpoint which led to
the failures of SPF -all, DomainKeys o=- and ADSP dkim=discardable.
DMARC has succeeded in large part because it has left this unworkable
viewpoint behind. The sooner you let go of the errors of the past,
the sooner you'll be able to make good use of DMARC.

We probably inhabit different universes. In mine, SPF -all "just works" and, most importantly, it allows the receiver to outsource onto the sender 100% of the blame arising from any non-deliveries because of SPF -all failures; also, in my universe DMARC has not "succeeded" -- not yet, at least.

[Roland Turner]

{{ Apologies, it appears that an incomplete version of this response was
sent rather than saved as a draft. }}

Post by J. Gomez
We probably inhabit different universes.

This is conceivable :-)

Post by J. Gomez
In mine, SPF -all "just works" and, most importantly, it allows the
receiver to outsource onto the sender 100% of the blame arising from
any non-deliveries because of SPF -all failures; also, in my universe
DMARC has not "succeeded" -- not yet, at least.

So:

* The test of SPF -all's effectiveness is not whether it can be turned
on without doing damage but whether it contributes materially to
preventing spoofing. It doesn't; spoofers can and do trivially pass SPF.
* Few receivers have the luxury of being able to blame others for
disrupting legitimate email flows. If you are one of those who can
get away with this, then by all means implement DMARC as-is. If it
suddenly turns out that your users aren't so blasé that "it's the
sender's fault" still washes, then you should of course either (i)
use it as an input to a more sophisticated defence strategy or (ii)
turn it off.


In terms of universes, I occupy the one in which >50% of all mailboxes
on Earth are already protected by DMARC filtering and which therefore
makes available to frequently spoofed domain owners a particularly
potent defensive tool. In this sense DMARC has already succeeded. (For
contrast note that SPF -all is implemented for far less than 50% of
mailboxes.)

The fact that this tool can't currently be used to prevent all spoofing
- and is never likely to be able to - doesn't mean that it hasn't
succeeded, merely that its application is limited, like any other tool.

Post by J. Gomez
For DMARC to be a viable option for receivers, it has to provide them
with a non-refutable answer/position for the cases when mail is not
delivered because of DMARC failures. If receivers are expected to
build a custom, fine-tuned, on-going maintenance-heavy local-only
system to deal with DMARC failure cases, because receivers cannot just
outsource onto senders the blame for DMARC failure cases, then most
receivers WILL NOT IMPLEMENT DMARC. My guess is many receivers will
not implement DMARC after having burned to much time and support costs
dealing with DMARC failure cases.

Two things:

* It's entirely likely that most receivers would decline to implement
DMARC with the current embryonic state of implementations and
supporting reputation data. This is not the same as saying that they
never will. In particular, much of the work of mapping reliable
forwarders and independent senders and competent/incompetent domain
owners can in principle be handled by reputation data providers just
as is currently the case for IP address blocklists (similarly,
creating IP address blocks lists is itself a task beyond reach for
most receivers but this isn't an argument for their not operating
mail-servers!) and, I'd suggest, such services are likely to appear
in the not-too-distant future.
* It may even be the case that most receivers will never implement. I
think this unlikely, but even if it happens this is hardly a
problem; the smallest 50% of receivers handle about 5% of all
mailboxes. Interdicting same-domain spoofing for only 95% of
mailboxes would be a pretty extraordinary success.


More broadly, DMARC has already succeeded, all additional receivers who
implement are just icing on the cake. Their participation is desirable
of course (blocking more spoofing is even better), and work to make that
easier is ongoing, but DMARC has already succeeded, it does not need
additional receivers in order to do so.

Post by J. Gomez

Post by Roland Turner
OK, this is perhaps the core of your misunderstanding. That a Domain
Owner expresses a policy which a receiver elects to ignore does not
mean that it's not a policy, merely that it's not binding upon the
receiver. One party's policy is the other party's recommendation,
suggestion or request.

One party's policy published for the consumption of the receivers, is a policy expected to be treated as policy by the receivers, otherwise it would be the first party's private-policy and not the first party's published-policy. If what I publish as policy is to be regarded as a song, then why do I bother publishing a policy instead of a song?

I have already published a policy that you give me all of your money. By
your reasoning, the fact that you haven't yet done so indicates that
there's something wrong with your behaviour.

Post by J. Gomez

Post by Roland Turner
This is not a contradiction, nor is it ex post
facto twisting; this is the plain English meaning of the word.

Policy is policy. That someone opts to not follow it, makes it an ignored policy, not a non-policy.

Thank you for agreeing with me; your statement contradicts your earlier
position.

Post by J. Gomez
Therefore, DMARC's policy of p=reject is best to be ignored. Or, in other words, there is not such a thing as a workable policy of REJECT in DMARC.

As has been pointed out to you ad nauseam, both of these assertions are
false.

- Roland

[Murray S. Kucherawy]

Post by J. Gomez
Is it true that if you reject incoming email which fails DMARC validation
and whose sender's policy is REJECT, then you are in for a world of hurt?
Yes, it is true. Therefore, DMARC'S p=reject is not something you can
trust, nor follow. Period. There is no clothing that puppet that is going
to change this truth about DMARC

Sure that's true, if one deals in absolutes. I had thought the email
community had learned many years ago that very little in the way of this
sort of work is deterministic; indeed there is ample evidence to the
contrary. Perhaps more specifically, we learned (or so I thought) during
the development of SPF and ADSP that it is impossible to make policy
statements that are absolute, because email is a complex beast whose myriad
aspects cannot be completely accounted for with simple policy statements.

Nobody has ever sold DMARC as a fire-and-forget silver bullet. I get that
this is the kind of thing the world would really like, and it appears that
this is how you're reading it. I'm sorry if you feel you've been misled,
but I also submit that thinking about email security in such terms is
rather antiquated.

If indeed it's the word "policy" that is causing you so much friction, it
would seem you have ignored Section 4 of the current draft. Nevertheless,
I am sure we would welcome your constructive suggestion about how better to
describe that part of the protocol.

I trust, however, that you are equally hostile toward SPF's "-all"
capability, given what the "P" in "SPF" represents? It's unfortunate that
the Proposed Standard version of the SPF RFC has already been approved, if
so.

Post by J. Gomez
It is the DMARC specification that chose to call it "policy", not
"recommendation". And policy is a policy, not a suggestion. Twisting words
to fit ex-post facto scenarios/realities is not funny.

To reiterate: It has been understood for some time that no actor can do
anything other than make a recommendation or a request no matter what one
calls it. In fact the current version of the DMARC base draft has language
in this area that's already been softened to indicate that it is only a
request or recommendation, even though it is called a policy (again,
Section 4). "Policy" has essentially become a term of art.

Perhaps you can spend your whole working day, day after day, fine tuning

Post by J. Gomez
your local DMARC processing secret-sauce. Good for you. Other people do not
have that luxury.

Nobody is forcing DMARC down their throat (or yours) either.

-MSK

[John Levine]

Post by Tim Draegen

Post by John Levine
If Paypal says to reject, I'm inclined to do it. If it's Linkedin,
I'm not.

Both LinkedIn and PayPal are doing incredible work to make email more
resilient to fraud, and they both encounter similar issues.

To some degree, although I see plenty of spam from Linkedin and no
spam whatsoever from Paypal.

If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list. Paypal realized that and fixed it,
Linkedin knows about if and chooses not to fix it. So nobody sensible
trusts Linkedin's advice unless they have elaborate meta-advice about
when DMARC advice is credible and when it isn't.

R's,
John

[Benny Pedersen]

Post by John Levine
If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list.

show an sample on that

if you forward dmarc protected mails you have to add the forwarding
mailserver ip into opendmarc ignorehost to prevent you from being
disconnected, its same with spf checking

and i think its sign of this maillist here is not supporting dmarc, not
linkedin that sooks :=)

i have not seen linkedin fail here, only fail linkedin do is to have a
ipv6 only hostname in mx

postfix logs this as a warning

and i begin to see more hosts that have mx hostnames with hostname in
mx, but no ip on that hostnames a or aaaa was missing

postfix logs this as a warning

Post by John Levine
Paypal realized that and fixed it,

good, if paypal stops adding https links into there campain emails
aswell, and only using https for custommers it would not be the most
phished site on phishtank

Post by John Levine
Linkedin knows about if and chooses not to fix it.

fix what ?

Post by John Levine
So nobody sensible
trusts Linkedin's advice unless they have elaborate meta-advice about
when DMARC advice is credible and when it isn't.

lol, you must show a sample here

[Roland Turner]

Post by Benny Pedersen
good, if paypal stops adding https links into there campain emails
aswell, and only using https for custommers it would not be the most
phished site on phishtank

How would _*not*_ using https _*reduce*_ phishing?

- Roland

[Roland Turner]

Post by John Levine
If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list. Paypal realized that and fixed it,

Are you referring to the 3rdparty._spf.paypal.com (and cousins) SPF
records or to something else. It does not appear that those records list
the outbound IP address for this list.

- Roland

[John R Levine]

Post by John Levine
Paypal staff don't subscribe to mailing lists with paypal.com addresses.

How did Paypal fix this? Did they tell their employees not to subscribe
compliance?

They subscribe from paypal-inc.com. As far as I can tell, it wasn't a
problem to get people to do it.

Regards,
John Levine, ***@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

[Christine Borgia]

How did Paypal fix this? Did they tell their employees not to
100% compliance?

That p=reject policy makes compliance much easier to get.

[Steve Atkins]

Post by Christine Borgia

How did Paypal fix this? Did they tell their employees not to
100% compliance?

That p=reject policy makes compliance much easier to get.

Only if those who receive the email actually follow that policy reliably. That’s not something I’m seeing much enthusiasm for (quite reasonably, given the sloppy deployment at some senders).

Cheers,
Steve

[Roland Turner]

Post by Christine Borgia

How did Paypal fix this? Did they tell their employees not to
100% compliance?

That p=reject policy makes compliance much easier to get.

True. I'd suggest that the importance to PayPal of thwarting spoofing
(and therefore a willingness to require their employees to do things
which might cause friction in lower-stakes environments) probably had
something to do with it.

- Roland

[Terry Zink]

Post by John Levine

If you blindly followed Linkedin's p=reject advice, you'd find yourself
bounced off this list. Paypal realized that and fixed it

Paypal staff don't subscribe to mailing lists with paypal.com addresses.

How did Paypal fix this? Did they tell their employees not to subscribe to mailing lists with @paypal.com addresses and then get 100% compliance? Or, did they give their employees a subdomain (e.g., email.paypal.com) and give their corporate employees that subdomain to subscribe as they see fit, and not publish a DMARC record for it (or p=none)?

-- Terry

-----Original Message-----
From: dmarc-discuss-***@dmarc.org [mailto:dmarc-discuss-***@dmarc.org] On Behalf Of John Levine
Sent: Wednesday, February 26, 2014 2:12 PM
To: dmarc-***@dmarc.org
Subject: Re: [dmarc-discuss] Disposition none on policy reject when DKIM and SPF fail

Post by John Levine

If Paypal says to reject, I'm inclined to do it. If it's Linkedin,
I'm not.

Both LinkedIn and PayPal are doing incredible work to make email more
resilient to fraud, and they both encounter similar issues.

To some degree, although I see plenty of spam from Linkedin and no spam whatsoever from Paypal.

If you blindly followed Linkedin's p=reject advice, you'd find yourself bounced off this list. Paypal realized that and fixed it, Linkedin knows about if and chooses not to fix it. So nobody sensible trusts Linkedin's advice unless they have elaborate meta-advice about when DMARC advice is credible and when it isn't.

R's,
John
_______________________________________________
dmarc-discuss mailing list
dmarc-***@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)

[John Levine]

Post by Benny Pedersen

Post by John Levine
If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list.

show an sample on that

Franck posts to this list, his DMARC says p=reject, and his messages
like everyone else's arrive with no DKIM or SPF that satisfies DMARC,
because that's what mailing lists do.

Post by Benny Pedersen
if you forward dmarc protected mails you have to add the forwarding
mailserver ip into opendmarc ignorehost to prevent you from being
disconnected, its same with spf checking

Well, yes, that's what I was saying. You need meta-policy information
to avoid shooting yourself in the foot from following DMARC policies.

Post by Benny Pedersen

Post by John Levine
Linkedin knows about if and chooses not to fix it.

fix what ?

Sigh.

R's,
John

[John Levine]

Post by Roland Turner

Post by John Levine
If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list. Paypal realized that and fixed it,

Are you referring to the 3rdparty._spf.paypal.com (and cousins) SPF
records or to something else. It does not appear that those records list
the outbound IP address for this list.

Paypal staff don't subscribe to mailing lists with paypal.com addresses.

R's,
John

[Roland Turner]

Post by John Levine

Post by Roland Turner

Post by John Levine
If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list. Paypal realized that and fixed it,

Are you referring to the 3rdparty._spf.paypal.com (and cousins) SPF
records or to something else. It does not appear that those records list
the outbound IP address for this list.

Paypal staff don't subscribe to mailing lists with paypal.com addresses.

Oh, I see what you mean.

- Roland

[John Levine]

Post by Matt Simerson
Applying p=reject on behalf of senders that ask for it barely ever hurts. If ever.

If you applied it to mail coming from this list, you'd have bounced
yourself off ages ago.

Clearly "apply" means different things to different people.

R's,
John

[John Levine]

Post by Matt Simerson
Until we have a solution that lets DMARC mail securely transit email lists, our two legged
DMARC table will wobble.

We have a perfectly good one that certain people are too pig-headed to
use: don't subscribe to lists from addresses with DMARC policies.

Speaking as someone who has run mailing lists for 20 years, I can
assure you that we didn't take useful features out of our list
software to deal with the last dozen FUSSPs, and we're not going to
change it to deal with DMARC. Forget it, don't waste your keystrokes
asking.

If you think your domain is so threatened that you need to publish
p=reject (which it probably isn't if your name isn't Paypal or
American Greetings, but that's a separate issue), then why isn't it
worth an extra 15 minutes of your time to set up a separate address in
a subdomain or at gmail to use for lists?

Remember, nobody has to accept your mail at all. To the extent that
you publish DMARC policies that increase other people's pain, they are
going to ease the pain by ignoring the policies, or perhaps by taking
your p=reject advice to its logical conclusion and throwing all your
mail away. I've already made a one-line config change to my lists to
do that. Who needs the grief?

R's,
John

[Murray Kucherawy]

Post by John Levine

Post by Benny Pedersen

Post by John Levine
If you blindly followed Linkedin's p=reject advice, you'd find
yourself bounced off this list.

show an sample on that

Franck posts to this list, his DMARC says p=reject, and his messages
like everyone else's arrive with no DKIM or SPF that satisfies DMARC,
because that's what mailing lists do.

I have a large collection of unsubscription notices from mailman as
evidence that this happens.

-MSK

[John Levine]

Post by Murray S. Kucherawy
This is an important point. Popular free filtering programs like
Spamassassin can be easily altered to take DMARC results into account as
input to the overall filtering decision. It's equally easy to add
exemptions for certain sources. The notion that applying DMARC in
non-absolute ways is out of the reach of the masses seems plainly false to
me.

Spamassassin already has some rules that do special case DKIM and SPF
handling for paypal, ebay, and other heavily phished domains whose
mail reliably passes DKIM or SPF. (It's in 60_whitelist*.cf and
60_adsp_override_dkim.cf.) Since they already have those, I have to
say at this point it's not obvious that adding DMARC to the mix would
make the filtering much better.

R's,
John

[John Levine]

Post by Dustin
As others have noted, DMARC does not deal with forwarding (or 3rd party
senders) well. This is seems to be a big barrier towards the credibility of
p=reject and DMARC adoption in general (and is also the reason I use
p=none).

Yes, exactly.

I have to say I'm dismayed that many people have learned nothing from
the past decade of arguments about SPF -all and DKIM ADSP and imagine
that the mail world will change the ways it works to conform to the
limitations of DMARC, despite the fact that the last umpteen times
anyone made that demand, the mail world ignored it.

DMARC can be quite useful, but it will be a lot more useful if people
use it in ways that are compatible with all the existing mail software
and stop imagining that it's up to the rest of the world to change.

R's,
John