Subject: Re: [dmarc-ietf] DMARC's purpose

From: Vlatko Salaj <[email-masked]>
Date: Sat, 12 Apr 2014 14:54:17 -0700 (PDT)

On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote:

> When I look at the feedback I get on my DMARC reports about 90% of the mail
> I send fails DMARC despite good SPF and DKIM deployments due to mailing lists,
> bug trackers, web site sharing, etc. For me and many others this is not about
> a trivial piece of the mail stream.

+1
my email actually fails 98%. but who cares about me, i'm no facebook sending
to yahoo, right? or yahoo sending to google... or some other big sending to
some other big... or whatever.

wrong.

come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but
in very narrow field.

this is what happens when a good idea gets half done, almost like a true
recipe for developing a quitter personal trait. or eating half baked bread.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Franck Martin <[email-masked]>
Date: Sat, 12 Apr 2014 18:31:53 -0500 (CDT)

----- Original Message -----
> From: "Vlatko Salaj" <[email-masked]>
> To: [email-masked]
> Sent: Saturday, April 12, 2014 2:54:17 PM
> Subject: Re: [dmarc-ietf] DMARC's purpose
> 

Don't publish a DMARC policy which is detrimental to you...

Also please correct your DMARC record, it is invalid: https://dmarcian.com/dmarc-inspector/goodone.tk

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 12 Apr 2014 22:49:15 -0400

On April 12, 2014 7:31:53 PM EDT, Franck Martin <[email-masked]> wrote:
>> > I send fails DMARC despite good SPF and DKIM deployments due to
>mailing
>> > lists,
>> > bug trackers, web site sharing, etc. For me and many others this is
>not
>> > about

What DMARC record would I need to make the Google Group I administer work correctly with Yahoo subscribers?  I am anxious to avoid detrimental DMARC policies. 

Scott K

---

From: Vlatko Salaj <[email-masked]>
Date: Sat, 12 Apr 2014 22:50:58 -0700 (PDT)

> Don't publish a DMARC policy which is detrimental to you...

it's "p=none". how is that detrimental to me? i don't plan changing it to
"reject" anytime soon.

dmarc still fails. and who will warrant me that some big esp doesn't get all
self-righteous and simply ignores my dmarc policy, instead choosing to process
my email according to its dmarc fail status? who says yahoo won't just decide
my email is a spam, that my domain is publishing "none" as any good phisher
would, and then simply process my email using dmarc filters, regardless of my
dmarc policy?

obviously a spec that isn't even a standard can't rly warrant me such a thing,
similarly to how yahoo doesn't care about obvious shortcoming in the current
spec, or even less, its recommendations.

let's all force our beliefs on world like yahoo did, and hope tranquility
will
be the result. pretty childish thinking.

> Also please correct your DMARC record, it is invalid:
> https://dmarcian.com/dmarc-inspector/goodone.tk

my dmarc record is perfectly valid, as per current spec. what's broken is
dmarcian.com check algorithm, which i reported to them two months ago, and
they acknowledged it.
why they didn't fix it yet, isn't my problem, but my
record is following current

spec.

i expected more from ppl on this list... u don't even know the spec, yet u
argue about it. great work all. just wonderful.

the only benefit from all dmarc crap for me is "fo=d:s" reporting policy.
at
least i get reports when spf and/or dkim fail.

dmarc alignment will always fail for me. yet my infrastructure isn't at all
rare, unique or uncommon, but actually pretty used practice.

so, at least i can
disable dmarc processing with "p=none" and that's my
recommendation to
all who believe in wide legitimacy of email natures.

you never know if recipients use forwarding without SRS, or whether their
infrastructure breaks DKIM, or even what type of SPF check they r doing,
cause even current SPF spec is defining evaluation uncertainties.

with "p=reject" policy your important email to some geeky admin on another
side of the planet may simply get lost, just because u have no control on how
ur email gets delivered or validated on their side. one forward here, one
anti-spam added header there, and walla, u r phishing from ur own email
account. congratulations.

no phisher would do it better.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 00:59:14 -0700

> come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well

Do you have any specific suggestions?

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Mon, 14 Apr 2014 10:10:38 -0700 (PDT)

On Monday, April 14, 2014 9:59 AM, Murray S. Kucherawy wrote:

> Do you have any specific suggestions 

as a matter of fact, yes, i do.

i already mentioned including SRS in check logic. unfortunately, no dmarc
author rly added much to the topic, and i work alone only on my own projects,
not on collaborative things as these.

also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st, would be:
a. dmarc alignment is a big issue. read: huge issue.
b. since alignment is an issue, make it policy optional.
c. by "make it policy optional" i mean: include an option in dmarc dns policy,
so that domain owners could turn dmarc alignment check on/off.

this could be useful for:
domains using high volume ML participation,
domains that use 3rd party services for their email infrastructure,
domains that use forwarders,
bunch of other special cases u can find on internet today and in future.

my 3rd suggestion, which would go nicely together with 2nd, is:
1. current dmarc spec uses OR logic while processing SPF and DKIM; why?

2. make this policy processing logic selectable.
3. by "make it selectable" i mean: include an option in dmarc dns policy,
so that domain owners could turn dmarc processing logic either to OR or AND.

my 2nd and 3rd suggestion, in combo, would deal much better with stuff
that, originally, dmarc spec had OR processing logic meant for, and while
doing that, it would also add so much needed wideness to dmarc rigidity.

and i could even pass dmarc finally. imagine that. while still getting some
benefit from dmarc processing.

is there a weakness in this proposal. probably. is it huge. i don't think so.
u disagree? elaborate, plz.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Apr 2014 14:39:24 -0700

I wouldn't take the lack of answers terribly personally.  There certainly
are a lot of threads to track right now.

As for your specific ideas:

> not on collaborative things as these.

I seem to remember there was in fact discussion of your SRS advocacy.

> so that domain owners could turn dmarc alignment check on/off.

One way of viewing DMARC is that it seeks to allow a domain owner to have
better control of how its domain is used, so I don't know what this would
accomplish.  If alignment is optional, what does DMARC do policy-wise that
DKIM and SPF don't already do?

> 1. current dmarc spec uses OR logic while processing SPF and DKIM; why?

They have complementary failure modes.  Data shows that the vast majority
of mail passes at least one if not both.  OR is the best logic in that
scenario, is it not?

> so that domain owners could turn dmarc processing logic either to OR or

That might be useful, but isn't that more restrictive, and not less
restrictive?  How would it help your use case, for example?

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Wed, 16 Apr 2014 22:50:32 -0700 (PDT)

On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote:

> I wouldn't take the lack of answers terribly personally.

i rly don't. i just found it rly lolable how everybody is whining about
ietf's purpose here, while list's main aim is about technical contributions
to the dmarc standard, which of, i saw none.

>> include an option in dmarc dns policy, so that domain owners could turn
>> dmarc alignment check on/off.

let me ask u: how exactly r u allowing a domain owner to have better control
of how its domain is used, when u do not allow it to say: i do not want
alignment? i imagine, domain owners may actually prefer to send their email
through 3rd party infrastructure. DMARC has no provisions for such practice.

and it's a common practice, absolutely. whether it's formal or informal.

>> include an option in dmarc dns policy, so that domain owners could turn
>> dmarc processing logic either to OR or AND.
> restrictive?

as i said: combined, alignment OFF and AND processing logic would work great
in cases where alignment isn't possible, yet email is fully legitimate.
and in such case, considering alignment requirement is gone, it's actually
less restrictive, while still providing better authentication. and blah blah,
u can see the benefit, i'm sure.

also, it should be strict AND, meaning, all dmarc mechanism must exist and
pass, for DMARC to pass, making such DMARC evaluation almost as reliable as
alignment-based one, if not more, while still encompassing much wider range of
email usage cases, in situation where it works better than alignment-based one.

also, there may be other algorithms in the future which will become part of
DMARC. allowing domain owners to have control of how these get evaluated is
a right thing to do. my proposal is even stronger if u consider that some of
these algorithms may get exploited in the future, which would completely
annihilate OR-based DMARC, with no remedy. having AND-based option would fix
that in advance.

> How would it help your use case, for example?

it would do wonders for me. my personal email stream would pass DMARC.

DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s"
would actually fix many of customer domains that i service, which use google
or yahoo mail for their domain-based email. considering both google and yahoo
use DKIM and SPF, those emails would pass such DMARC, even thought they are
being sent through 3rd party services. and if DKIM and SPF get supported by
other services, it would cover them too.

also, making alignment and logic selectable, would not make additional
pressure on big ESPs infrastructure, but it would cover much of failure
cases current version has.

it may even be worthwhile for big ESPs to use this type of DMARC policy:
"reject", alignment OFF, logic AND, reporting ON. it would surely make
reports they receive much more informative too, helping with data mining
on other domain practices, which could be used in anti-spam etc.

and any potential abuse would simply be dealt with by switching to alignment
ON policy, when it's required for a particular domain.

>> author rly added much to the topic

none rly taking the discussion to next lvl, but merely acknowledging i
mentioned SRS, and dismissing it without much ado.

also, i have another suggestion:
include sender-id as another DMARC supported check algorithm.

sender-id is different enough from SPF to cover many usage scenarios,
and would just add to dmarc strengths. i don't rly understand why ppl take
sender-id for 2nd generation SPF, since it isn't.

yeah, i better not start this topic... we don't want another MARID.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Apr 2014 23:22:29 -0700

> through 3rd party infrastructure. DMARC has no provisions for such

"I do not want alignment" is exactly the same as "I don't use DMARC" since
DMARC is pretty much all about alignment.  So, again, I don't understand
why that's a useful thing to add.

> and it's a common practice, absolutely. whether it's formal or informal.

What's an example?

> u can see the benefit, i'm sure.

For the "off" case, isn't that just the same as "p=none"?

For the "and" case, yes, that's possible to add if there's enough demand to
add it.  So far the people that have tried this are satisfied with the "or"
logic.  What do others think?

> email usage cases, in situation where it works better than alignment-based

Sure, if that's what the community wants to do.  This is the first time
I've heard anyone say this would be a useful thing to support.  If anyone
else agrees that it's needed, DMARC can easily be extended to include this
capability.  It's built that way.

> annihilate OR-based DMARC, with no remedy. having AND-based option would

Yes, that extensibility is already built into DMARC.

> it would do wonders for me. my personal email stream would pass DMARC.

By turning off alignment, I bet it would.

> other services, it would cover them too.

What would that look like, exactly?  From: your domain, a passing DKIM
signature for a domain other than yours, a passing SPF test for a domain
other than yours?  If that's what you mean, then I can make any message I
want that passes DMARC for your domain by sending it from my own box and
signing it.  Are you sure you want that?

If that's not what you mean, then you'll have to build an example, because
I don't get it.

> cases current version has.

Actually I think if you advertise something that is substantially weaker
than what DMARC has now, I suspect ESPs will be less likely to trust your
stream because it's basically unprotected.

> mentioned SRS, and dismissing it without much ado.

That probably means the benefit of adding SRS support wasn't obvious to the
people responding.  This may be obvious to you, but it's apparently not
obvious to others.

> yeah, i better not start this topic... we don't want another MARID.

I totally agree there, especially since Sender-ID got almost no adoption
(see RFC 6686), and that seems unlikely to change now.

-MSK

---

From: "Popowycz, Alex" <[email-masked]>
Date: Thu, 17 Apr 2014 07:42:32 -0400

Perhaps I'm missing something, but eliminating alignment essentially nullifies the authentication value for a given domain. If, for example, I disable alignment then I'm essentially saying that anyone can hijack/spoof/misappropriate my domain as long as they have a validspf record for the sending mta or DKIM sign their message.

Example. My domain is legitimatemail.com. I have a DMARC record that has set alignment to OFF.
Someone, either known to me out not, now sends using the FROM address of legitimatemail.com but signs with d=badmail.com. It seems with the proposal below that would "pass" DMARC processing and be delivered (or at least not get rejected due to DMARC). I guess I fail to see how this works towards reducing/eliminating fraudulent email.

-----Original Message-----
From: Vlatko Salaj [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 17, 2014 01:50 AM Eastern Standard Time
To: [email-masked]
Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals

--
Vlatko Salaj aka goodone
http://goodone.tk

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Joseph Humphreys <[email-masked]>
Date: Thu, 17 Apr 2014 09:57:56 -0400

At one time I suggested adding a feature to list domains that could be
considered "in alignment" with yours. So if a domain owner wanted to
authorize an email service provider, they could just add something to their
DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or
DKIM signing. I am still curious what's wrong with this proposal. It seems
to me to cover Vlatko Salaj's use case, and would certainly be easier to
implement than arranging to share a DKIM key.

Regards,
Joe Humphreys

On Thu, Apr 17, 2014 at 7:42 AM, Popowycz, Alex <[email-masked]>wrote:

>  Perhaps I'm missing something, but eliminating alignment essentially
> nullifies the authentication value for a given domain. If, for example, I
> disable alignment then I'm essentially saying that anyone can
> hijack/spoof/misappropriate my domain as long as they have a validspf
> record for the sending mta or DKIM sign their message.
>
> Someone, either known to me out not, now sends using the FROM address of
> legitimatemail.com but signs with d=badmail.com. It seems with the
> proposal below that would "pass" DMARC processing and be delivered (or at
> least not get rejected due to DMARC). I guess I fail to see how this works
> towards reducing/eliminating fraudulent email.
>
> *From: *Vlatko Salaj [[email-masked]]
> *Sent: *Thursday, April 17, 2014 01:50 AM Eastern Standard Time
> *To: [email-masked]
> *Subject: *Re: [dmarc-ietf] alignment and parsing logic as optionals
>

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 17 Apr 2014 07:51:16 -0700 (PDT)

On Thursday, April 17, 2014 8:22 AM, Murray S. Kucherawy wrote:

> For the "and" case, yes, that's possible to add if there's enough demand
> to add it. So far the people that have tried this are satisfied with the
> "or" logic.

making DMARC strictly based on OR-logic will get it obsolete as soon as
someone finds a way to exploit any of the underlying mechanism, and that's
already possible, either through DKIM replay attack, or through spoofed SPF
authentication, whichever serves an attacker better.

and if DMARC gets expanded by any additional mechanism, it will just make it
weaker, with OR-dependency.

> "I do not want alignment" is exactly the same as "I don't use DMARC"
> since DMARC is pretty much all about alignment. So, again, I don't
> understand why that's a useful thing to add.

it's not the same. DMARC is not just authentication, it's also about reporting
and conformance. i would be perfectly happy to get my email checked against
SPF and DKIM and processed in a standard-defined way, and receive reports on
which i can then act. otherwise, DMARC has no benefits for me at all.

>> and it's a common practice, absolutely. whether it's formal or informal.

i've already written about it. someone using yahoo or google email service
to send their own domain email. i actually do that. and i imagine, a great
deal of ppl.

it also covers various 3rd party services, such as ones that deliver greeting
cards, process petitions...

> For the "off" case, isn't that just the same as "p=none"?

it isn't. if we accept the idea about making alignment optional, i would
gladly expand the idea to more than just turning alignment on/off.

actually, such alignment field would, in my proposal, include a three-state:

1. alignment ON, in which case from: header gets checked against.

2. alignment OFF, in which case domain owner specifies they have no benefit
from DMARC alignment checks, but do want other checks performed, such as
AND-logic mechanism evaluation, for example.

3. alignment domain-list value to include in alignment check: list of domains
the domain owner wants to have included in DMARC alignment check, complementing
from: header domain; this will cover almost all cases DMARC breaks now, such
as 3rd party infrastructure, mailing lists that do not wish to make changes
for DMARC-compatibility, forwarders that process their mail, but can't be
controlled by domain owner, etc. it's somewhat similar to SPF domain definition,
but different, since it affects DMARC-alignment process.

> That probably means the benefit of adding SRS support wasn't obvious to
> the people responding. This may be obvious to you, but it's apparently
> not obvious to others.

SRS has benefits. but not for big ESPs, mainly cause of infrastructure
requirements. so, i'm done with advocating for that, cause it won't get
supported by the most influential actors here, that's obvious.

> (see RFC 6686), and that seems unlikely to change now.

it would change quite fast if we would make it part of DMARC.

actually, Sender-ID isn't all that bad at all. it was way ahead of its time.

PRA could actually be a better way to determine owner's domain for alignment
purposes than some undefined public-suffix list, especially in the light of
newest moves by ICANN, introducing bunch of new top-lvl domains, which will
probably host a bunch of sub-domains with registration capabilities by 3rd
parties, etc.

DMARC's dependance on a concept of "public-suffix list" is a can of worms
i can't wait to see what will make of DMARC's usability at the end. it will be
a mess for sure. i'm not rly sure how this isn't obvious to DMARC's authors,
given all that experience in the domain.

On Thursday, April 17, 2014 1:42 PM, "Popowycz, Alex" wrote:

> nullifies the authentication value for a given domain.

which, in some cases, has no value at all. as i mentioned up, alignment-OFF
works well only with other options i'm proposing, and only in special cases.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 17 Apr 2014 15:41:59 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Vlatko Salaj
> Sent: Thursday, April 17, 2014 10:51 AM
> To: [email-masked]
> > For the "and" case, yes, that's possible to add if there's enough
> > demand to add it. So far the people that have tried this are satisfied
> > with the "or" logic.
> 

There isn't much that someone can do with a DKIM replay attack in a DMARC context because the entire body and key headers are signed. For spoofed SPF authentication, the answer is DNSSEC. If DNSSEC is broken/exploited then the community will have larger issues than DMARC.

> weaker, with OR-dependency.

This may or may not be true. It depends on the specific additional mechanism.
> and conformance. i would be perfectly happy to get my email checked
> against SPF and DKIM and processed in a standard-defined way, and receive
> reports on which i can then act. otherwise, DMARC has no benefits for me at
> all.
> 

Then just publish p=none. You get your email checked and you get your reports. The discussion is about those domain owners that are seeking a higher level of protection.

> i've already written about it. someone using yahoo or google email service to
> send their own domain email. i actually do that. and i imagine, a great deal of
> ppl.
> 

Don't drag greeting cards into this fight. We've sent billions of greeting card notifications on behalf of our customers in a DMARC conformant way (and as I've pointed out, even before DMARC was a gleam in anyone's eye) without any problems whatsoever. Other greeting card companies have followed our lead in publishing SPF and DKIM signing but I'm not in a position to comment on their specific implementations and configurations. Third party services such as greeting cards are actually a much different use case than mailing lists. 

> 
> >> as i said: combined, alignment OFF and AND processing logic would
> >> work great in cases where alignment isn't possible, yet email is fully
> legitimate.
> it isn't. if we accept the idea about making alignment optional, i would gladly
> expand the idea to more than just turning alignment on/off.
> 
> 
> from DMARC alignment checks, but do want other checks performed, such
> as AND-logic mechanism evaluation, for example.
> 

If I were evil I could consistently defeat this every day of the weak without much effort. This was the same problem with PRA and the use of Sender. When I first pointed this out to Microsoft (this is not intended to pick on them) back in the 2006 timeframe, they told me it was my implementation that was the problem. When I sent them crafted emails showing that I could consistently get a neutral under PRA checking for ANY From domain (abusing the sender field) they agreed that this was a problem.

> from: header domain; this will cover almost all cases DMARC breaks now,
> such as 3rd party infrastructure, mailing lists that do not wish to make
> changes for DMARC-compatibility, forwarders that process their mail, but
> can't be controlled by domain owner, etc. it's somewhat similar to SPF
> domain definition, but different, since it affects DMARC-alignment process.
> 

This doesn't scale. How many domains would a large mailbox provider have to include in the list to account for all domains subscribed to by their users? How short would the TTL have to be in order to work for newly subscribed to domains? Where would this list live? The DNS folks would freak even if the list weren't too long to be put in a DNS record.

> 
> > That probably means the benefit of adding SRS support wasn't obvious
> > to the people responding. This may be obvious to you, but it's
> > apparently not obvious to others.
> 
> > I totally agree there, especially since Sender-ID got almost no
> > adoption (see RFC 6686), and that seems unlikely to change now.
> 
> PRA could actually be a better way to determine owner's domain for
> alignment purposes than some undefined public-suffix list, especially in the
> light of newest moves by ICANN, introducing bunch of new top-lvl domains,
> which will probably host a bunch of sub-domains with registration capabilities
> by 3rd parties, etc.
> 

As I indicated above, PRA had a serious flaw that allowed it to be gamed. Microsoft dropped support for Sender-ID in favor of SPF. Is it worth spending time on something which is basically deprecated/historic?

> DMARC's dependance on a concept of "public-suffix list" is a can of worms i
> can't wait to see what will make of DMARC's usability at the end. it will be a
> mess for sure. i'm not rly sure how this isn't obvious to DMARC's authors,

The public-suffix issue is a known one that impacts things other than DMARC. There are proposals on how to address this issue but I have to admit to personally not following them or their progress - only so many cycles in the day. Could you identify any specific instances where public-suffix has been a significant (or non-significant) problem in the wild?

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 17 Apr 2014 09:35:59 -0700 (PDT)

On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote:

> At one time I suggested adding a feature to list domains that could
> be considered "in alignment" with yours. So if a domain owner wanted
> to authorize an email service provider, they could just add something
> to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom
> and/or DKIM signing. I am still curious what's wrong with this proposal.
> It seems to me to cover Vlatko Salaj's use case, and would certainly be
> easier to implement than arranging to share a DKIM key.

finally, somebody that sees things from perspective other than a big sender.

also, plz notice, working with DKIM 3rd party support is not only pretty messy,
but usually not a supported option. so, DMARC badly needs its own solution
for this alignment problem.

On Thursday, April 17, 2014 5:42 PM, MH Michael Hammer (5304) wrote:

> Third party services such as greeting cards are actually a much different
> use case than mailing lists.

if, and only if, it's built in DMARC-compatible way. and this isn't all that
natural or intuitive.

it seems DMARC wants to change everything to have it compatible with itself.

i can understand how this benefits big players. it's just pity big players
don't understand how this doesn't work for small players, aka 90% of the net.

> If I were evil I could consistently defeat this every day of the week
> without much effort.

domain owner publishing alignment-OFF policy wants such policy. who cares
if anyone can beat it? it's their decision and they r ready to suffer
consequences for whatever reason. at least they have an option.

maybe they just want to process SPF and DKIM in a standard way, as defined
by DMARC. without DMARC "reject" rule, they lose that.

>> the domain owner wants to have included in DMARC alignment check,
>> complementing from: header domain
> This doesn't scale.

it scales the same way it scales for SPF. i see no problem there.

also, scaling isn't rly an issue for big ESP. they will just use alignment-ON
and force everyone to adapt. just like yahoo did recently.

alignment domain-list is of great value to small domains. i'm quite sure
this would be one of the most used tags in DMARC policy, if included in spec.

> Microsoft dropped support for Sender-ID in favor of SPF.

merely cause it's not widely adopted. not because it's completely broken.

> When I sent them crafted emails showing that I could consistently get
> a neutral under PRA checking for ANY From domain (abusing the sender field)
> they agreed that this was a problem.

neutral result isn't a pass, under current DMARC evaluation rules.
so, it's not the same situation as with plain Sender-ID check.

> Could you identify any specific instances where public-suffix has been
> a significant (or non-significant) problem in the wild?

yes, i can. almost any new free domain service will have issues with this,
until such public-suffix picks it up... which is yet another nightmare of
infrastructure support. as i said, we r opening a can of worms here,
especially where ICANN is moving with top-lvl domains.

i saw it happening with Symantec's SafeWeb as well as all other URL checking
services developed in recent years. it's a mess and needs high maintenance.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: John Sweet <[email-masked]>
Date: Thu, 17 Apr 2014 09:52:30 -0700

On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote:

> DKIM signing. I am still curious what's wrong with this proposal.
>

How is this not covered by SPF "include:"?

If your message has both MAILFROM and RFC822 From: aligned on your domain,
and the connecting IP is in the range of the included domain, it's all good.

J

---

From: Joseph Humphreys <[email-masked]>
Date: Thu, 17 Apr 2014 13:18:38 -0400

On Thu, Apr 17, 2014 at 12:52 PM, John Sweet <[email-masked]> wrote:
>> DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM
>> signing. I am still curious what's wrong with this proposal.
>
>

I just replied to a similar question from John Levine, that I'm trying
to support a use case where SPF will not be in alignment: a
third-party sender that wants to handle bounces on behalf of the
author. Vlatko Salaj also brought up the case of using gmail to send
mail with a From header in your own domain. (Gmail seems to use your
gmail address as the MAILFROM address.)

Just to generalize the point: requiring alignment for the purpose of
using SPF to authenticate the From header has the unintended (I think)
consequence of restricting the Return-Path to the same domain.

An aligned-domain list would not have this consequence.

Regards,
Joe Humphreys

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 17 Apr 2014 10:32:41 -0700 (PDT)

On Thursday, April 17, 2014 6:53 PM, John Levine wrote:

>> I don't see any scaling problem for the case of a domain used by a single
>> entity that wants to authorize a few service providers to send email on
>> its behalf.
> Is that really a problem? I was under the impression that a sender either
> adds the providers' IPs to their SPF record, or gives them a DKIM signing key.

wrong:
1. DKIM key sharing requires such a support, which is usually not there.
2. SPF policy check doesn't evaluate ur SPF policy at all, but ur ESP's.

On Thursday, April 17, 2014 6:53 PM, John Sweet wrote:

>> I am still curious what's wrong with this proposal.
> How is this not covered by SPF "include:"? If your message has both MAILFROM
> and RFC822 From: aligned on your domain, and the connecting IP is in the
> range of the included domain, it's all good.

it isn't covered by SPF's "include:".

seems not many understand this problem, let me make an example:
if i use yahoo email for my goodone.tk domain, yahoo will send my email
with yahoo.com DKIM key and with yahoo.com SPF MailFrom [my yahoo account
address].

and i can't do anything about it. yahoo doesn't support key-sharing, nor
it will.

so, my domain-email sent from yahoo mail isn't aligned. however, it is
legitimate, it is DKIM-signed and it has proper SPF.

out of my 15 small-business customers, 12 use exactly this usage scenario.
usually google. and when i said it would be a problem, that was not the best
way, trying to force them to send mail through their own server, they didn't
want to hear it.

and i imagine, it is a pretty common practice in the wild for small players.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "J. Trent Adams" <[email-masked]>
Date: Thu, 17 Apr 2014 12:02:57 -0600

Vlatko -

On 4/17/14 11:32 AM, Vlatko Salaj wrote:

[ snip ]
> and i imagine, it is a pretty common practice in the wild for small players.

I see your use case, and why the alignment issue is problematic.

And you've prompted me to wonder if we need to layer in the concept of
"authorized use" in addition to how we've been talking about technical
email authentication. In this flow, your email is authenticating with
SPF and DKIM, but you're running into an issue where Yahoo no longer
authorizes their domain to be used in that flow.

To start, we need to agree that a domain owner is permitted to authorize
how it's domain can be used. Then, when a domain owner publishes a DMARC
record, they're announcing to the world that their domain can only be
used to send email in a specific way (i.e. "aligned").

It's this concept of authorized use that we may be missing in the
conversation. Heavily abused domain owners have empirical evidence to
prove that alignment is a key factor to blocking spoofed domain abuse.
And they are now in a position to authorize those methods they
determined to be less susceptible to abuse.

That's not to say that other uses are invalid, just that they fall
outside what the domain owner is authorizing. And, in the use cases
you're suggesting, it sounds like mailbox providers such as Yahoo are
telling the world, "Due to being heavily abused, we are no longer
authorizing the practice of using our domains in that way."

I'm not sure that gets us closer to a workable solution, but perhaps the
shift in perception helps shake loose some ideas.

HTH,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 17 Apr 2014 14:04:20 -0400

>> easier to implement than arranging to share a DKIM key.

That seems like it would only work if one is designating only one, or a 
small number of ESPs.  It doesn't seem to address the mailing list case 
- Yahoo's subscribers, en masse, belong to a huge number of lists, 
hosted all over the place.  Which scales about as poorly as SPF (if you 
do mailing lists, you end up back at v= +all.

So we're back to managing whitelists.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Joseph Humphreys <[email-masked]>
Date: Thu, 17 Apr 2014 14:38:24 -0400

On Thu, Apr 17, 2014 at 2:04 PM, Miles Fidelman
<[email-masked]> wrote:
> small number of ESPs.  It doesn't seem to address the mailing list case -
> Yahoo's subscribers, en masse, belong to a huge number of lists, hosted all
> over the place.  Which scales about as poorly as SPF (if you do mailing
> lists, you end up back at v= +all.
>

I agree that it does not solve the mailing list case. It solves at
least two other cases. If someone has a solution that solves all
cases, I will gladly forget about this solution.

Regards,
Joe H

---

From: Tomki Camp <[email-masked]>
Date: Thu, 17 Apr 2014 12:37:57 -0700

While I do not think that Yahoo! would have opted for this level of
enforcement, I do think the variation in alignment requirement could be
interesting, and useful in some cases.

What about a scenario where a user would like to
- receive DMARC reporting
- request DMARC-aware receivers reject email which does not pass base
authentication measures (SPF or DKIM), but not apply the next step of
alignment enforcement

This could still be beneficial in cutting off illegitimate email which
does not pass SPF or DKIM at all, but provides the allowance which some
domain owners could find a useful middle or even final step in their DMARC
deployment.

Could it be set up as allowing aspf=n for “align SPF = none” and adkim=n?
Could the application be considered when the request is given as
“adkim=n;aspf=r”, meaning “DKIM alignment not required; if the DKIM
signature passes at all, this is a pass.  SPF alignment required in
relaxed mode; to pass DMARC-SPF, SPF must pass and be in alignment”

--
Tomki

-----Original Message-----
From: "J. Trent Adams" <[email-masked]>
Date: Thursday, April 17, 2014 at 11:02
To: Vlatko Salaj <[email-masked]>, "[email-masked]"
<[email-masked]>

---

From: "Popowycz, Alex" <[email-masked]>
Date: Thu, 17 Apr 2014 16:13:38 -0400

But if your ESP is where your email originates, then citing them in your SPF is appropriate.  

If you're worried about the impact of DMARC then:
a) Don't publish a DMARC record 
b) Publish a DMARC record with p=none or 
c) Publish any DMARC policy but use an SPF record like "v=spf1 ip4:0.0.0.0/0 ~all

As for small domains being able to send DMARC compliant mail, (not trying  to market Google's capability... but) that's easily accomplished with Gmail using your own DKIM key that's published on your own DNS entry for your personal/small business domain. 

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Vlatko Salaj
Sent: Thursday, April 17, 2014 1:33 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals

wrong:

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 17 Apr 2014 13:42:47 -0700 (PDT)

> But if your ESP is where your email originates, then citing them in your

wrong conclusion, but i'm not gonna repeat myself.
one example should be enough to everybody.

> As for small domains being able to send DMARC compliant mail,
> (not trying  to market Google's capability... but) that's easily
> accomplished with Gmail using your own DKIM key that's published
> on your own DNS entry for your personal/small business domain.

which isn't free. thus, u r trying to market google's capabilities, while

missing the point.

-- 

Vlatko Salaj aka goodone
http://goodone.tk

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 17 Apr 2014 13:50:59 -0700 (PDT)

> Could it be set up as allowing aspf=n for “align SPF = none” and adkim=n?

i find this a convenient way of introducing alignment-OFF logic, yes.

also, aspf and adkim tags would be a best place for alignment domain-list, imo.

for example "aspf=n,r:yahoo.com,s:google.com" would mean none alignment for
from: header domain, relaxed alignment for yahoo.com and strict alignment
for google.com. the domain in this question uses yahoo and google mail services
to send mail, and doesn't use its own servers at all.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Apr 2014 23:04:24 -0700

> one example should be enough to everybody.
I think if you want to get your ideas understood and thus adopted, you're
going to have to set your patience and politeness thresholds a lot higher
than they are now.

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 17 Apr 2014 23:20:21 -0700 (PDT)

> I think if you want to get your ideas understood and thus adopted,
> you're going to have to set your patience and politeness thresholds
> a lot higher than they are now.

i do not have much patience for ppl that have no time to read step by step
example, but do have time to write a lengthy response, while missing the point
and promoting commercial services.

i was tired and i apologize for the tone, but not for the point i was making.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 01:44:16 -0700

> authentication, whichever serves an attacker better.

The DKIM replay attack assumes that either (a) the entire content is
signed, in which case the only replay is the re-sending of a complete
original (which is presumably valid), or (b) there's partial content
signing going on, which is strongly discouraged practice anyway.

What's an example of spoofed SPF authentication?

> which i can then act. otherwise, DMARC has no benefits for me at all.

So you don't want the authentication enforcement, only the reports?  Isn't
that what "p=none" does?  You would get reports of unaligned mail and
SPF/DKIM results in that case already.

> cards, process petitions...

It seems to me more like you're talking about a way to extend specific
other domains to be allowed to send mail as your domain and still pass.
SPF and DKIM already have mechanisms to do that, not to mention
experimental extensions like ATPS.  The problem is that you need to know
ahead of time which senders will do so, which has the obvious scaling
problem.  Of course, since DMARC is about keeping control over that, maybe
it's an expected scaling problem, but it's still something that needs to be
handled.

> gladly expand the idea to more than just turning alignment on/off.

I still don't understand this.  What's the difference between "p=none" and
what you're calling "alignment off"?

> AND-logic mechanism evaluation, for example.

But the AND-logic is "SPF and DKIM have to pass, and be aligned".  So
you're saying both need to pass (in the AND case), but it doesn't matter
which domains they validated?  Again, that means I can send any mail I want
as your domain and that would pass DMARC, and I'm not clear about why you
want that.

3. alignment domain-list value to include in alignment check: list of
> domains
> complementing
> such

Right, that's the third-party case discussed above.  There are a bunch of
limitations, assuming this is something that's actually in enough demand to
add.  For starters: (1) sticking the list in a DNS TXT field will not scale
(suppose you want to authorize a thousand third parties), and (2) you have
to keep the list current, which will need automation and security around it
as users seek to add entries (by subscribing to lists, for example).

> it would change quite fast if we would make it part of DMARC.

What would be the value in doing so?

> alignment

I don't think we really want to re-have the MARID arguments.  The fact that
in several years nobody adopted Sender-ID speaks pretty loudly to me.

> given all that experience in the domain.

It is obvious.  Appendix A.6 even acknowledges that the public suffix
method is "far from perfect", and that if and when any better mechanism
appears, DMARC should change to use it.  There has been work appearing in
the IETF's Applications Area to create such a system, but there's nothing
formal or deployed yet.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 01:44:41 -0700

> and promoting commercial services.

Reaching consensus requires dialog and patience, and sometimes needs more
than just one example.  There's a lot of smart people here who have been
working on this for a long time, probably with very different perspectives
and experience than you have.  Assuming they're all dumb or lazy because
they're "missing the point" seems like a pretty bad place from which to
start.

If all people get is snark when they probe your ideas, I'm pretty sure
they'll just stop answering.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 01:58:26 -0700

> authentication measures (SPF or DKIM), but not apply the next step of

What's the next step part?  If you've rejected the message because it
passes neither SPF or DKIM, it seems like you're done with that message
irrespective of alignment.

> domain owners could find a useful middle or even final step in their DMARC

Shooting from the hip, I'm inclined to say this is out of scope for DMARC.
DMARC has as one of its core tenets the notion of From: field alignment,
because what the user sees comes from the From: field for most (almost
all?) MUAs.  If you take that out of the equation, it seems like we're
talking about stuff a layer below DMARC, not DMARC itself.

> Could it be set up as allowing aspf=n for “align SPF = none” and adkim=n?

If you're going to say "either has to pass but I don't care about
alignment", then I can use my own domain in the MAIL FROM or sign with my
own domain and send mail with your domain in the From:, and it'll pass the
DMARC test.  Is that really an attractive alternative?

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 18 Apr 2014 04:01:15 -0700 (PDT)

On Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy <[email-masked]> wrote:

> Assuming they're all dumb or lazy because they're "missing the point"
> seems like a pretty bad place from which to start.

didn't happen.

> they'll just stop answering.

also didn't happen.

why do u exactly defend someone who promoted google's commercial services?

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 18 Apr 2014 05:32:35 -0700 (PDT)

On Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy <[email-masked]> wrote:

> So you don't want the authentication enforcement, only the reports?

no, i do want authentication enforcement. i do not want alignment enforcement.
i want parsing of both SPF and DKIM in AND-based logic and i want it
standardized, and standardized rejection based on failure of such parsing,
and standardized reporting, and standardized introduction in anti-spam
filters.

hint: "standardized" is the point here. if that, somehow, isn't obvious.

> Isn't that what "p=none" does?

nope. "p=none" simply excludes my email from DMARC completely. i do get
reporting, but i don't get standardized parsing, or standardized rejection
on failure, or standardized anti-spam filtering introduction, or whatever
else builds on DMARC in the future.

> So you're saying both need to pass (in the AND case), but it doesn't
> matter which domains they validated?
> Again, that means I can send any mail I want as your domain and that
> would pass DMARC, and I'm not clear about why you want that.

cause u r not fixing alignment problems u introduced in DMARC, and i have no
other choice but to disregard alignment completely, yet i also don't care
about possible phishing that much, cause either my domain doesn't get phished
much or SPF/DKIM/anti-spam filtering on receivers' side works well in such
cases, which brings me back to alignment again and how i don't care about
alignment or how u don't want to fix it, so i decide i'll just turn it off,
instead of bickering on DMARC mailing list about fixing the alignment problem,
which u don't want to fix, cause u keep saying it's a feature.

and came the time when google started defending problems as features.

however, as i said, DMARC is way more than just alignment, and i do care
about those other things, especially if there's AND-logic in the standard.

10 goto _top

> Right, that's the third-party case discussed above.
> There are a bunch of limitations, assuming this is something that's
> actually in enough demand to add.

and what does "enough demand to add" mean? who decides about what's enough,
in this, adhoc something which isn't even an ietf approved wg?

> For starters: (1) sticking the list in a DNS TXT field will not scale
> (suppose you want to authorize a thousand third parties), and

i just love how u r gonna authorize a 1000 3rd parties with DKIM-key sharing,
instead. nice discussion we have here. maybe next time i can make ridiculous
contra argument like this on some of ur new ideas, just to be fair.

> (2) you have to keep the list current, which will need automation and
> security around it as users seek to add entries (by subscribing to lists,
> for example).

i guess u r intentionally missing the point here. i have no other idea why
it is so hard to read when i write "small players", few domains, or whatever
else i wrote while trying to paint this "small" picture for everybody here.

so, it's not 1000 domains, 4000 IPs, 50000 servers. it would be, on average,
imo, 2 domains [for those who actually use the setting, which is already a
special case, not a common practice].

> Of course, since DMARC is about keeping control over that,
> maybe it's an expected scaling problem, but it's still something that
> needs to be handled.

which isn't enough of a reason against.

> What would be the value in doing so?

alignment-pass in various special cases i'm trying to cover here with my
proposals, which currently have alignment-fail status.

if Sender-ID was part of DMARC, my "goodone.tk email stream coming from
yahoo mail use case" would be solved instantly. it would also cover mailing
lists, and whatnot, just because of benefits Sender-ID has over SPF.

so, if Sender-ID was a part of DMARC-underlying mechanisms, i would drop all
my proposals, cause my troubling case scenarios would be solved, as well
as many others.

> The fact that in several years nobody adopted Sender-ID
> speaks pretty loudly to me.

this is like saying that there r no business politics in protocol world.
right.

it's pretty obvious Sender-ID was a collateral victim of general
displeasure with Microsoft's business model. who knows, we may soon see
the same happening to Google too... if it haven't started already.

> experimental extensions like ATPS.

DMARC's alignment problem isn't SPF's or DKIM's problem. and if u r
suggesting i should use DKIM extensions, which r rarely supported,
or other tools, to fix problems DMARC introduces, then i'll just quit this
mailing list, and ignore the entire protocol, cause it's broken and
u r telling me u don't want to fix it.

ps. i hope nobody felt threatened by my somewhat ironical tone in this message.

--
Vlatko Salaj aka goodone
http://goodone.tk