Subject: [dmarc-ietf] confusing 3rd party support so it remains out

From: Vlatko Salaj <[email-masked]>
Date: Thu, 5 Jun 2014 00:35:57 -0700 (PDT)

it seems to me that many of DMARC defenders don't understand
main points of proposed 3rd party solutions, confusing them
for ML solutions, and thus dismissing them altogether.

while it's true 3rd party support for DMARC would be able
to solve ML DMARC problems, that path would most likely
be used only by small domains, whose users rely heavily on
mailing lists, and where there's already some trust between
domain-owner and MLs.

it's surely not a ML solution for entities like ESPs.

that doesn't mean it's not possible, even for domains such
as Yahoo. it merely means such domains would prefer to rely
on simple and performance friendly rigid logic.

however, that, again, doesn't mean 3rd party support isn't
REQUIRED.

i have no idea why it's not obvious to so many experts
here, but my best guess is that their viewpoints are limited
by their own environment.

most of u seem to look at the problem from ur big towers,
trying to create a protocol that suits ur big towers.
however, many small buildings get smashed while u do so.
not very nice.

small domains do such extensive and complex things with
their email path, one would find crazy, and for multiply
of reasons: to suit their needs, their users, their finances,
u name it. and it's all pretty legitimate and
standards-respecting. yet, they r being excluded. excluded
cause they r not a big tower environment.

very shortsighted, if u ask me. there's only so many
big towers; world is populated with houses.

so, to me, it's obvious current DMARC alignment requirements
are just too rigid for real world, and anyone who doesn't
realize it is not only cracking down on the usefulness of
email, but in a way, sinking their own ship [and i'm looking
at yahoo here].

btw, i can already see cpanel/plesk/whatever developers
ignoring support for DMARC in their software, limiting it
only to DNS records publishing, without any receiver support.
and i can see many receivers disrespecting p=reject altogether
from overzealous domains, turning the protocol into
whitelisting, essentially.

nobody wants to break their customers email with a rigid
standard [excluding 200kg gorillas in a porcelain shop].

ps. to state an example, if anybody doesn't get it.
i have trust in ymail to send email on behalf of my domain,
and i want a way to state that in my DMARC policy.

pps. and no, there's no abuse hole there. ymail verifies
ownership of an email address added to yahoo account, and
only the account that verified it can send such email
through ymail. am i crazy to trust ymail on such things?
maybe, but that's solely my decision. not DMARC's.

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

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 5 Jun 2014 22:22:20 +0200

> for ML solutions, and thus dismissing them altogether.
(...)
> and i want a way to state that in my DMARC policy.

Thanks for the example, makes it so much clearer.

For that use case, you should do an SPF-include of Yahoo's SPF inside your own SPF record. Yes, provided Yahoo had any SPF at all (which they did not until very recently), and also provided the included-SPF already involved less that 10 DNS-queries.

If those conditions were false, I would take it as an implied declaration from ymail that your use case is not welcome with them, so why force the issue with them?

Regards,
J.Gomez

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 5 Jun 2014 14:10:10 -0700 (PDT)

On Thursday, June 5, 2014 10:22 PM, J. Gomez <[email-masked]> wrote:

> For that use case, you should do an SPF-include of Yahoo's SPF
> inside your own SPF record.

nope, that doesn't work. ESPs send email using account's
original address during SMTP MAIL FROM, not user's 3rd
party address. in my case that's @yahoo.com, not @goodone.tk.

and that's perfectly regular and quite logical, since
that's the address that is transmitting email. it would
be wrong for any ESP to claim they send email for a domain
they don't control. only domain-owner can do that.

however, while DMARC was created exactly for something
like that [domain owners specifying how they want their
mail treated], it doesn't offer such choice.

so, ur suggestion just shows how DMARC ppl don't
understand wide scale of broad email usage scenarios.

if DMARC had Sender-ID as one of underlying protocols,
sure, that would work, since Sender-ID does PRA processing,
which covers bunch of these scenarios, including ML,
forwarding, broad 3rd party, whatever...

however, for the sake of this discussion, it's obvious
DMARC MUST include some 3rd party support, or it will be
a failure at the end, as much as many previous policy
attempts, now merely historic references.

and, btw, i do have ymail in my domain's SPF. it's there
for Sender-ID compatibility. not that it matters for this
discussion.

currently, DMARC rigidity excludes my usage scenario, and
that's wrong.

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

---

From: Brandon Long <[email-masked]>
Date: Thu, 5 Jun 2014 14:42:18 -0700

Let me see if I understand this... you want to be able to use a strong
DMARC setting for your domain, and let YMail send mail on behalf of your
domain?

Most here are arguing against using strong DMARC settings for personal use
cases, you are arguing for 3rd party support because you do want to use
DMARC?

For consumer Gmail, you'd have one option, to set up outbound-msa and have
your email go through your own mail server to be signed or allow the
envelope sender to align for SPF.

For Google Apps, you have several more options, including giving us a dkim
key for your domain that we'll use to sign your messages, or smarthosting
and other advanced routing options for using your own mail server (or a
third party server).

Theoretically, we could include a DKIM signature option for consumer Gmail,
but that seems like a 1% of 1% feature that's unlikely to be much use.
 There's an argument for having a "Gmail for your own domain" product, but
the more one looks at that, the more it ends up being Google Apps.  Its
unfortunate that TPTB removed the free version of GAFYD.

Even if something like TPA-labels was established to give third parties
permission, I'm not clear if/how that would affect YMail/Gmail's handling
of "custom from", "allow custom from if TPA-Label exists at send time"?

Brandon

On Thu, Jun 5, 2014 at 2:10 PM, Vlatko Salaj <[email-masked]>
wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2014 22:43:35 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-

I think the use case here is for hosted mailing lists for small
entities.  I was on a call with some ESPs the other day, and they said
the number of lists for church groups and scout troops and the like is
huge, most of them use the list owner's individual e-mail address at a
consumer ISP or mail provider, and in most cases there is no practical
way for them to use an address in their organization's "official"
domain.  This is somewhat different from discussion lists since the
messages typically originate from a web form at the ESP, not the
author's mail provider, so O-A-R approaches don't work since there's
no O to A.

It's a real issue.  All of the solutions scale pretty badly, but
approaches that start by enumerating reasonably trustworthy ESPs seem
less awful than something that requires cooperation from the users'
mail providers.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Thu, 5 Jun 2014 15:47:24 -0700

On Thu, Jun 5, 2014 at 3:43 PM, John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >

So, this is the constantcontact or announce list solution, ie instead of
just using their mail client directly (possibly because of sending limits)?

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 5 Jun 2014 19:11:04 -0400

> just using their mail client directly (possibly because of sending limits)?

It's not just sending limits, it's also list management and message design 
tools.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "J. Gomez" <[email-masked]>
Date: Fri, 6 Jun 2014 03:55:07 +0200

> party address. in my case that's @yahoo.com, not @goodone.tk.

Yes, and why is that a problem for the use case you stated?
 
When you said "i have trust in ymail to send email on behalf of my domain", were you meaning that you wanted ymail using your domain in the MAIL-FROM envelope (1), or in the Header-From field (2)?
 
If (1), that would be something unreasonable to expect from ymail, and please explain why would you need it. If (2), please explain whether ymail allows it or not, and if not please explain why would that be a DMARC limitation instead of a ymail limitation.
 
You should describe your indented use case with more detail, I'm afraid I'm not following your reasoning here.

> understand wide scale of broad email usage scenarios.

It's a way to put it. Another way would be: your use case is obscure and you shed no light on it.

> currently, DMARC rigidity excludes my usage scenario, and

Please, explain with more detail how is your usage scenario excluded by DMARC. I fail to see how, as described by you up to now, is your usage sceneario impeded by DMARC instead of by ymail/whatever, given that DMARC leverages SPF and SPF has the concept of includes available to you.

Regards,
J.Gomez

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 01:14:51 -0700 (PDT)

> Let me see if I understand this... you want to be
> able to use a strong DMARC setting for your domain,
> and let YMail send mail on behalf of your domain?

i want to use whichever DMARC setting suits me, and
to allow trusted 3rd parties to send email on my behalf.

> Most here are arguing against using strong DMARC
> settings for personal use cases, you are arguing
> for 3rd party support because you do want to use DMARC?

what's the point of DMARC then? r we building a
safer email, or r we just introducing protocols
that can't be used cause they r not-to-be-used
from the start? ppl r arguing against strong
DMARC settings cause they r broken, not cause
they r not useful.

> Even if something like TPA-labels was established
> to give third parties permission, I'm not clear
> if/how that would affect YMail/Gmail's handling

i don't see how or why would 3rd party support in
DMARC change anything regarding ymail 3rd party
email account capability. it wouldn't, cause it
has little to do with it.

ps. and no, i don't want to pay for google services.
and i don't want to use my own MTA, cause that's
not the point. i want to send email the way
i trust it to be sent, using whatever ESP i trust.

pps. by not including 3rd party support in DMARC,
u actually have to build more than one complex
workaround just to workaround DMARC's inefficiency,
just as u specified in ur examples. it's trivially
obvious to me that adding 3rd party support would
be much less complex, much easier, with much
better control... at least to majority of domains.

is using aidbands better than actually patching up
the patient?

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

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 01:49:08 -0700 (PDT)

On Friday, June 6, 2014 3:55 AM, J. Gomez <[email-masked]> wrote:

> When you said "i have trust in ymail to send email on behalf of my domain",
> were you meaning that you wanted ymail using your domain in the MAIL-FROM
> envelope (1), or in the Header-From field (2)?

(1) no.
(2) yes.

> If (1), that would be something unreasonable to expect from ymail,
> and please explain why would you need it.

yes, as i said, no one expects such a broken behavior, so i don't.

> If (2), please explain whether ymail allows it or not,

it does.

> and if not please explain why would that be a DMARC limitation instead
> of a ymail limitation.

well, since it does support it, i guess there's nothing to answer here,
but let me make as plain as possible example:

===
FROM header: [email-masked]
MAIL-FROM envelope: [email-masked]
DKIM domain: yahoo.com
===

results:
1. mail legitimate; validated by sending ESP using:
2. valid DKIM @yahoo.com,
3. servers validated by SPF at yahoo.com,
4. goodone.tk SPF records r of no importance here,
5. DMARC is unable to authenticate this email: no 3rd party support.

> Another way would be: your use case is obscure
> and you shed no light on it.

actually, this is a pretty common practice, especially
for personal or small business domains. out of my 15
business customers, 13 use exactly this. and i mainly
support small business, so my experience is pretty
in line with this world, unlike, i imagine, ppl working
for ymail, google, paypal, fb or whoever sat and designed
DMARC.

> Please, explain with more detail how is your usage
> scenario excluded by DMARC. I fail to see how, as
> described by you up to now, is your usage sceneario
> impeded by DMARC instead of by ymail/whatever, given
> that DMARC leverages SPF and SPF has the concept
> of includes available to you.

i hope u understand now. if not, i won't be able to
provide more str8-forward examples of this scenario,
cause i'm not able to specify it more clearly than this.

i hope others understand my example.

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

---

From: José Ferreira <[email-masked]>
Date: Fri, 6 Jun 2014 10:23:29 +0100 (WEST)

----- Original Message -----
> From: "Vlatko Salaj" <[email-masked]>
> To: [email-masked]
> Sent: Friday, June 6, 2014 9:49:08 AM
> Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out
 
> 5. DMARC is unable to authenticate this email: no 3rd party support.

Just to keep this out of the Y! realm, GApps also does this for Domain alias.

example.com : primary domain
example.net : alias domain

FROM header       : [email-masked]
MAIL-FROM envelope: [email-masked]
DKIM domain       : example.net

Makes some sense to be this way but DMARC will always fail for example.net.

José Borges Ferreira
AnubisNetworks

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 06 Jun 2014 18:48:59 +0900

> to allow trusted 3rd parties to send email on my behalf.

AFAICS, DMARC was designed to deal with phishing for credentials via
fraudulent messages claiming to be from customer service of a large
large business entity.  This is a big hurt *all by itself*, and so
worth a whole protocol to reduce it.  The reason is that even with a
low "conversion rate" on the phishing message, individual customers
can be hurt very badly, and the profits are big enough that there's
strong incentive to engage in email fraud for this purpose alone.

You have a different use case, you need a different protocol.

 > what's the point of DMARC then?

Building safer email, one brick at a time.  You need a different
brick.  Why delay DMARC implementation because your brick isn't baked
yet?

 > ppl r arguing against strong DMARC settings cause they r broken,

But they're not broken when used in a "direct mail" context.  The "on
behalf of" use cases and the "mailing list" use case are a harder
problem.  Standardizing DMARC (in or out of the IETF process) is a
case of "don't let the best be the enemy of the good."

 > is using aidbands better than actually patching up

It is if you have a Band-Aid, but lack a sterile needle and thread to
properly suture the wound.  We *don't have* a protocol for your use
case yet.  Many proposals have been made, but they all failed because
some party essential to the success of the protocol would refuse to
cooperate. :-(

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 07:09:15 -0700 (PDT)

On Friday, June 6, 2014 2:56 PM, Stephen J. Turnbull <[email-masked]> wrote:

> large business entity.

and how is my use case different? is it cause:
1. i don't have a phishing problem?
2. i'm not a big money entity?

choose ur answer wisely, and beware how u thread.

if ur answer is 1: u don't know that. and it's not ur business to know
that. if i wish to protect my domain from phishing, it is my sole
right to do so. it is also my sole right to do it the way i trust is
sufficient for me.

if ur answer is 2: building protocols that suit big tower corporations
is just like net neutrality discussion we have now at FCC.

just like FCC's recent corrupted moves to promote what was almost
unimaginable a few years back, which, even if successful, will be
dismissed sooner than later, and whole fiasco will be looked as a dark
history of internet, DMARC support will be left out by worldwide
developers, cause it's a complete waste of their time and energy, and
doesn't serve high goals it proclaims it does.

i will repeat myself: nobody will develop a support for a lousy
protocol that has a high probability of breaking delivery of a
perfectly legitimate email, while trashing everything developed for
email last 20y or more: mailing lists, forwarding, send2friend, and
whatever 3rd party email processing someone imagine useful to them.

if u rly want DMARC to succeed and have a wide scale support, u will
do ur best to adapt it to internet at large. otherwise, u will be left
with a half-baked protocol supported mostly by the same entities that
developed it. and that's not whole internet. not even close.
neither that solves ur phishing problems completely, as the rest of
internet will ignore ur DMARC records completely and let ur phishing
take place.

why? cause u failed to develop a protocol useful to all parties.

so all that energy and work will go to waste, when IETF puts
"historic" on DMARC standard, and moves on to some better place.

> Why delay DMARC implementation because your brick isn't baked yet?

cause building houses while missing some bricks will surely result in
their collapse at some point. and then u will have profit loses when
ur reputation as a builder gets tarnished by angry customers
obsessing with ur customer support.

considering how many things DMARC doesn't support, that's actually
a logical consequence.

> Standardizing DMARC (in or out of the IETF process) is a

i would rather say it's a case of "history repeating". how many
email policy protocols were developed in last 10y? a bunch of them.
all of them failed. all of them "historic" now.

why? cause they were unlucky enough to be half-baked.

DMARC has a chance. will it use it? i'm quite sure it won't...

why? cause, unless genius and creativity kicks in early in development
process, things produced r usually mundane and mediocre. that's how
DMARC feels now.

but at least i'm giving my best not to let that happen. it must be
that period of my life when a completely unknown individual
openly and unconditionally contributes essential stuff to a future
success. or i just care enough. whichever suits u to agree with me.

it's beyond obvious DMARC needs a 3rd party support. every email
standard has it: SPF has it, DKIM has bunch of them, ESPs have them,
websites have them... name any email thing that works on wide scale
and take a few seconds to realize what's its 3rd party support
in its basic functions.

>> is using aidbands better than actually patching up the patient?
> case yet.

actually, AFAICS, we have three complete solutions for 3rd party support,
and that's counting last few months, not from the beginning of DMARC
development, which may have produced many different solutions; and i
don't doubt it did, cause problems r obvious and real.

the real problem with 3rd party support for DMARC r DMARC "gate-keepers".
they r like FCC now, listening to small minds from big towers, reluctant
to make "a small step as a jump for email kind".

> Many proposals have been made, but they all failed because

if DMARC doesn't assimilate some kind of 3rd party support soon, it
will be a failure too. and i don't think it has much time left:
1 year probably, 2 years if u r rly pushing it.

ppl already dismiss DMARC as a failure... and i don't blame them.

having it at IETF as an informational RFC speaks volumes on its fate.
if it was actually beneficial to internet, it would go most common and
regular IETF standards track.

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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 07 Jun 2014 02:32:41 +0900

> and how is my use case different? is it cause:

2.  DMARC is designed for business entities big enough to be willing
    to maintain MTAs to do the signing for them, or pay for somebody
    trustworthy to maintain such an MTA for them.  You aren't willing,
    so your use case is different.

That doesn't mean your use case isn't important.  It means that DMARC
isn't designed for it.

I don't have a protocol that works for your use case.  If you have
one, propose it and see if you can get Yahoo! to agree to use it.  But
Yahoo! hasn't done it for you, and I'll bet you they won't -- they're
not particularly interested in your use case.

 > standard has it: SPF has it, DKIM has bunch of them, ESPs have
 > them, websites have them... name any email thing that works on wide
 > scale and take a few seconds to realize what's its 3rd party
 > support in its basic functions.

I'm not sure what you mean by 3rd party support in SPF and DKIM.  Can
you put a third party mailbox in From: with SPF?  Sure.  *And nobody
trusts it, and nobody should.*  Anybody with an account at Yahoo! can
put your mailbox at your domain in From:, and it will pass SPF
authentication as Yahoo!.  Ditto DKIM.  That's not support.

Yahoo!'s use of "p=reject" causes you pain?  Tell Yahoo! about it.  Or
switch to GMail.

 > actually, AFAICS, we have three complete solutions for 3rd party

What are they?  AFAICS, there are none, but I'm willing to be
educated.

 > ppl already dismiss DMARC as a failure... and i don't blame them.

DMARC is working for the people who designed it (and they claim to
represent 80% of the users in the US and 2 billion mailboxes
worldwide).  Unfortunately, this is not one of those cases where it
happens to work for everybody else.  A shame, but "there ain't no such
thing as a free lunch."

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Jun 2014 10:50:26 -0700

> doesn't serve high goals it proclaims it does.

The current deployed base of DMARC appears to disagree.  Setting aside
Yahoo! and AOL (the controversial cases), there are several operators who
have been using DMARC for quite some time now that don't cause problems and
they have enjoyed huge benefit from it.

> whatever 3rd party email processing someone imagine useful to them.

Reality appears to differ.  PayPal, Bank of America, and Facebook at least
have been using it for a long time, and I'd bet you didn't even notice.

> "historic" on DMARC standard, and moves on to some better place.

I have to assume you're referring to ADSP here, which was recently marked
"Historic".  However, DMARC has already enjoyed more adoption than ADSP
ever did, even with its controversy.  I think I know some of the reasons
why, and we can go into them if you like.

> all of them failed. all of them "historic" now.

Which ones, other than ADSP?

> and take a few seconds to realize what's its 3rd party support

Although SPF and DKIM do have third party delegation tools (in DKIM's case,
at least two), they have never had much uptake.  Perhaps that will change
as DMARC continues to evolve, but so far the industry as a whole (not the
IETF) has not found their use to have more benefit than risk.

> don't doubt it did, cause problems r obvious and real.

To answer Stephen's question, I'm guessing you're referring to ATPS (RFC
6541), use of CNAME to point to an externally-posted key, and a key
exchange where an operator give a third party a signing key.  If there are
others, I'd like to know what they are.

All three would require the Yahoo!s and AOLs of the world to grant signing
keys, signing key aliases, or ATPS records to every domain that might
re-send their mail.  There are some obvious issues with such solutions: (a)
users will have to register every list to which they subscribe and wish to
post; (b) they will have to automate DNS updates because every new entry
into that registry will require a new DNS entry; and (c) if any of those
third parties gets compromised, it's a big problem for the domain trying to
protect itself.  If any bit of this fails (and I suspect (a) is actually
the bigger problem), they don't work.

> to make "a small step as a jump for email kind".

I don't think that's a fair characterization.  I think the more likely
explanation is that the proposals on the table are much too risky and
costly given the benefits.  If a better one comes along, I'm sure it would
be considered.

> regular IETF standards track.
The status of the current document has nothing at all to do with the
quality of what's in it, but rather the procedural path it's taking toward
publication.  On the Independent Submission track, the only status
available is Informational.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 07 Jun 2014 03:38:50 +0900

Murray S. Kucherawy writes:

 > To answer Stephen's question, I'm guessing you're referring to ATPS
 > (RFC 6541), use of CNAME to point to an externally-posted key, and
 > a key exchange where an operator give a third party a signing key.
 > If there are others, I'd like to know what they are.

Though they *are* solutions technically, I don't consider any of those
"complete", in that I presume that Yahoo! has not offered any of those
solutions to Mr. Salaj.  And, for the reasons you give, confirmed by
the fact that it hasn't happened yet, I believe they aren't going to
do so any time soon.

Steve

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 11:47:24 -0700 (PDT)

On Friday, June 6, 2014 7:33 PM, Stephen J. Turnbull <[email-masked]> wrote:

> DMARC is designed for business entities big enough to be willing

be free 2 enlighten me with a link to DMARC draft section saying
exactly that, cause i can't find it.

also, u r here directly contradicting bunch of other DMARC developers
who stated exactly the opposite numerous times.

ASAIK internet standards r standards for all, not wealthy and mighty.
maybe i'm living in a dream world.

> I'm not sure what you mean by 3rd party support in SPF and DKIM.

SPF: u can put 3rd party servers in ur domain's SPF records that
send email on ur behalf.
DKIM: TPA, and other proposed standards similar to it. search for it.

> Can you put a third party mailbox in From: with SPF? Sure. *And nobody
> trusts it, and nobody should.*

if u r so nice to make an example for this, cause i sure can't figure
out how would anything like this work.

> Anybody with an account at Yahoo! can put your mailbox at your domain
> in From:, and it will pass SPF authentication as Yahoo!. Ditto DKIM.

no they can't. only owners of a domain address can do such a thing,
since every 3rd party domain email address gets validated 1st.

so, ur point, invalid. be free to try ur example urself.

> Yahoo!'s use of "p=reject" causes you pain?  Tell Yahoo! about it.
> Or switch to GMail.

i don't rly care about yahoo's "p=reject". it just shows how
DMARC is broken as it is, but it doesn't affect me much.
nor do i care to use gmail, or trust it.

>> actually, AFAICS, we have three complete solutions for 3rd party
>> support

i'm not a search engine. but it seems u r not following this mailing list.

> A shame, but "there ain't no such thing as a free lunch."

sure there is. it even has a name - FOSS. it's also called
open standards. it's also called free books. and let's not forget
all those free kitchen for homeless.
why am i even commenting on this...?

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

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 12:06:41 -0700 (PDT)

On Friday, June 6, 2014 7:50 PM, Murray S. Kucherawy <[email-masked]> wrote:

> PayPal, Bank of America, and Facebook at least have been using it
> for a long time, and I'd bet you didn't even notice.

i did notice bunch of MTA errors in infrastructure i'm supporting, that
previously weren't there, all DMARC errors on legitimate email.

> Which ones, other than ADSP?

i'm not a search engine. but one could even argue that SPF, Sender-ID
and bunch of DKIM addons were exactly in that group.

> To answer Stephen's question, I'm guessing you're referring to ATPS,
> use of CNAME to point to an externally-posted key, and a key exchange where
> an operator give a third party a signing key.

nope, i'm not referring to any of DKIM's 3rd party support. we r in DMARC
mailing list. i'm referring to DMARC 3rd party support proposals, all of
which have been mentioned many times on this mailing list.

> I think the more likely explanation is that the proposals on the table
> are much too risky and costly given the benefits.

i see no risks with me publishing a DMARC records saying exactly this:
do DMARC alignment against yahoo domain too.

and i'm sure u can't find any, other than breaching yahoo itself,
my account, or my dns records, all of which isn't DMARC's field of
protection anyway.

be free to make an example, i would really like to see what additional
risks and costs u r mentioning. if possible, ofc.

> The status of the current document has nothing at all to do with the quality
> of what's in it, but rather the procedural path it's taking toward
> publication.

anyone can trust whatever they like. but considering u work for ur DMARC
bosses as a document shepard... i'll just consider u biased in evaluating
this.

nobody interested to fix email would publish such a protocol as independent
RFC. more brains, better solutions, more contributions, better standard...
there have been many calls to make a working group.

but, they don't want a working group, they don't want somebody else taking
control, fixing stuff that's broken, cause they would be forced to introduce
support for it. why would they care, right? they build it for themselves.

very caring, for sure. no wonder major US ICT companies r losing reputation.

so many times we make same mistakes...

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

---

From: "Popowycz, Alex" <[email-masked]>
Date: Fri, 6 Jun 2014 15:10:17 -0400

As an implementer of DMARC in a large institution and also on my personal domain, I don't believe there are limitations in the deployment of the protocol solely at the large scale, as along as individuals doing so understand what potential ramifications it might have. As admittedly a stretch analog, S/MIME could be viewed similarly since it "breaks" email in MUAs that don't support it.

On the institutional side, it's been extremely successful in mitigating the risks stemming from email attacks (e.g. phishing) for traffic destined to mailboxes supporting the protocol.

On the personal side, even though my volumes are but a trickle, it's been effective in ensuring the integrity of my domain from spammers, etc from MTAs as far flung as Sudan, Vietnam, Argentina, India and many other locations around the globe. So I would have to say out of personal experience that it's not solely for the "wealthy and mighty" as you put it.

My point being that even individuals care to protect those their message for those who might otherwise be tricked into some malicious activity because of the trust placed on the source address (and the individual behind it). While DMARC may have had a focus on transactional messaging, its use shouldn't be precluded from other situations.

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Vlatko Salaj
Sent: Friday, June 06, 2014 2:47 PM
To: Stephen J. Turnbull
Cc: [email-masked]
Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out

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

---

From: Brandon Long <[email-masked]>
Date: Fri, 6 Jun 2014 12:46:14 -0700

> exactly that, cause i can't find it.

I think its inherent in it.  To use DMARC, you have to be able to
authenticate your mail using either SPF or DKIM.  Doing that requires
running a server that does it or using a service which does it.

There is nothing that says that YMail has to support your use case, if you
want DMARC auth'd mail for your domain, you're going to have to use a
service which supports it.  Either run your own, or pay someone who offers
the service.

There are those who think we must move to an authenticated sender world.
 In that world, either we have a third party auth system (which we don't),
or third parties need to have the ability to provide auth (upload a dkim
key, include: for SPF).  Neither or those things are particularly in the
wheelhouse for the average consumer on a free service, and its not clear to
me that those services would be willing to add the complexity to handle it,
knowing that the user is then on the hook for editing domain entries.
 Heck, the domain registrars are more probably more likely to offer
smtp-msa service instead... well, if there's enough money in it for them.

Brandon

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 12:50:48 -0700 (PDT)

On Friday, June 6, 2014 9:10 PM, "Popowycz, Alex" <[email-masked]> wrote:

> On the institutional side, it's been extremely successful
> in mitigating the risks stemming from email attacks (e.g. phishing)
> for traffic destined to mailboxes supporting the protocol.
> On the personal side, even though my volumes are but a trickle,
> it's been effective in ensuring the integrity of my domain from
> spammers, etc from MTAs as far flung as Sudan, Vietnam, Argentina,
> India and many other locations around the globe.

interesting.

let me guess, none of these undocumented examples is
fmr.com, the domain u r posting here from, which, as of today,
isn't protected by any DMARC policy record, but merely a "p=none",
which, ofc, isn't a protection as u specified in ur post.

since there's no webserver behind that domain, i guess that's
ur personal domain, but i'm willing to accept it's something
completely else.

or u meant DMARC essentially didn't protect u, but provided
reports upon which u might have had acted. not that such case
counts as a point towards DMARC protection usability or
efficiency, actually; it dismisses ur DMARC praise completely,
instead.

if that's the case, i'll guess i'm just not fool enough.

> While DMARC may have had a focus on transactional
> messaging, its use shouldn't be precluded from other
> situations.

sure it SHOULDn't. but it is. i'm still waiting on 3rd party support.

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

---

From: "J. Gomez" <[email-masked]>
Date: Fri, 6 Jun 2014 22:17:00 +0200

On Friday, June 06, 2014 10:49 AM [GMT+1=CET], Vlatko Salaj wrote:

> > When you said "i have trust in ymail to send email on behalf of my
> > domain", were you meaning that you wanted ymail using your domain
> > in the MAIL-FROM envelope (1), or in the Header-From field (2)?
> 
> (1) no.
> (2) yes.
> 
> 
> well, since it does support it, i guess there's nothing to answer
> here, but let me make as plain as possible example:
> 
> ===

I think DMARC would be able to authenticate that email as long as GOODONE.TK included in his SPF record the SPF record of YAHOO.COM. In that case, DMARC checking for DKIM would fail, but DMARC checking for SPF would find that the Header-From domain is aligned with SPF, therefore the net result would be a DMARC pass.

If the particular SPF record of YAHOO.COM does not lend itself to be SPF-included with third parties (as it uses the "redirect" mechanism), that is not a SPF problem nor a DMARC problem, instead it is a YAHOO.COM problem and an implicit declaration from YAHOO.COM that your use case does not fit with them (but if you don't have your own MTA, then again your use case could indeed fit with YAHOO.COM).

> cause i'm not able to specify it more clearly than this.

I don't understand why you say DMARC impedes your described use case, as I keep seeing that a simple SPF-include in your own SPF record --which you control yourself-- would make your use case DMARC-compliant.

> i hope others understand my example.

I hope so too, so that I can be enlightened about why am I wrong.

Regards,
J.Gomez

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 13:14:49 -0700 (PDT)

On Friday, June 6, 2014 9:46 PM, Brandon Long <[email-masked]> wrote:

> To use DMARC, you have to be able to authenticate your
> mail using either SPF or DKIM.

i am.

> Doing that requires running a server that does it or
> using a service which does it.

i am - ymail. it authenticates it's own DKIM signatures
and SPF servers on my email perfectly. for free, imagine that.

> There is nothing that says that YMail has to support your use case.

ymail supports my use case. DMARC doesn't: it needs 3rd party support.

i need nothing from ymail, they have been doing wonderful job for me
13y now.

i need DMARC alignment rigidity gone. and some wise ppl to accept it.
well, we may lack that, i guess.

> or third parties need to have the ability to provide auth (upload a dkim key,
> include: for SPF).

or simply we add 3rd party support to DMARC. and walla, we r there.

ps. all messages to this mailing list r failing DMARC.
just so u ppl know. my forwarder keeps annoying me about that.
please fix it. ohhh, yes, u can't. sorry for mentioning. at least
u can say receivers u don't care about DMARC, right? imagine if they
didn't include DMARC-ignore in records, either.

btw, i do find it ironic how messages to a mailing list about
DMARC r failing the same protocol they mean to discuss.
just the way world works, i guess. ppl make broken stuff, then
defend them as if sky will fall if they gets fixed.

pps. i'll just turn off my DMARC testing scripts... i have enough data.
anybody wants to see it? actually, there's nothing to tell what i
didn't say already anyways.

ppps. i'm quite sure many ppl here have enough of my posts for a lifetime.
so, i'll just stop replying now, as there's very little i can additionally
say, beyond mocking various posters for their obvious incapability to
follow my posts or whatever, which isn't my intention, interest or pleasure.

i will keep in touch if u eventually fix DMARC, sure.
but i predict u won't.

so, farewell.

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

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 13:30:00 -0700 (PDT)

> I think DMARC would be able to authenticate that email as long as
> GOODONE.TK included in his SPF record the SPF record of YAHOO.COM.

well, u think wrongly.
i suggest rereading both of SPF, DKIM and DMARC drafts.

> If the particular SPF record of YAHOO.COM does not lend itself
> to be SPF-included with third parties (as it uses the "redirect"
> mechanism), that is not a SPF problem nor a DMARC problem,
> instead it is a YAHOO.COM problem and an implicit declaration
> from YAHOO.COM that your use case does not fit with them
> (but if you don't have your own MTA, then again your use case
> could indeed fit with YAHOO.COM).

omg. u rly don't know much about SPF...

> I hope so too, so that I can be enlightened about why am I wrong.

good luck getting help on this mailing list, lol.

maybe some DMARC's 3rd party support supporters can replace me
here, cause i lost all my interest in participating in this
black hole called DMARC mailing list, for now.

sorry for that.

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

---

From: "Talamo, Victor" <[email-masked]>
Date: Fri, 6 Jun 2014 20:56:02 +0000

I concur with Alex.  Attached is very dated list of DMARC adopters from sometime last year and it is in no way comprehensive. The list is simply a sample to identify dmarc adopters, and included a mix of senders and receivers adopting DMARC. With that said if you check the DMARC records for these domains today, the vast majority of these domains are DMARC REJECT comprising billions of emails. Enough said.

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Vlatko Salaj
Sent: Friday, June 06, 2014 3:51 PM
To: Popowycz, Alex
Cc: [email-masked]
Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out

On Friday, June 6, 2014 9:10 PM, "Popowycz, Alex" <[email-masked]> wrote:

> On the institutional side, it's been extremely successful in 
> mitigating the risks stemming from email attacks (e.g. phishing) for 
> traffic destined to mailboxes supporting the protocol.
> On the personal side, even though my volumes are but a trickle, it's 
> been effective in ensuring the integrity of my domain from spammers, 
> etc from MTAs as far flung as Sudan, Vietnam, Argentina, India and 
> many other locations around the globe.

interesting.

let me guess, none of these undocumented examples is fmr.com, the domain u r posting here from, which, as of today, isn't protected by any DMARC policy record, but merely a "p=none", which, ofc, isn't a protection as u specified in ur post.

since there's no webserver behind that domain, i guess that's ur personal domain, but i'm willing to accept it's something completely else.

or u meant DMARC essentially didn't protect u, but provided reports upon which u might have had acted. not that such case counts as a point towards DMARC protection usability or efficiency, actually; it dismisses ur DMARC praise completely, instead.

> While DMARC may have had a focus on transactional messaging, its use 
> shouldn't be precluded from other situations.

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

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 6 Jun 2014 14:18:34 -0700 (PDT)

On Friday, June 6, 2014 10:56 PM, "Talamo, Victor" <[email-masked]> wrote:

> With that said if you check the DMARC records for these domains today,
> the vast majority of these domains are DMARC REJECT comprising billions
> of emails.

billions of notification email. that barely anyone reads. and that
nobody cares if gets lost.

i can only hope to see real data on number of DMARC false-positives
in that billions of notification email, but i'm sure that would
just completely crash any trust in DMARC, so we will never see it.

exactly the reason behind DMARC being an independent document on IETF.

not that i care anymore. it's a waste of my time, obviously.

'nuff said.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Jun 2014 15:02:43 -0700

> and bunch of DKIM addons were exactly in that group.

None of them are Historic.  SPF was just upgraded to Proposed Standard, and
DKIM is a full standard; both are in pretty heavy use.  Sender-ID is
probably a failed experiment at this point though.

ADSP is the only one I can think of.  I'm happy to be enlightened.  You'll
have to suggest some search terms, because I couldn't find any other than
the ones we've already listed here, except maybe VBR.

> risks and costs u r mentioning. if possible, ofc.

I did provide some examples of the cost of the current third-party systems
in my previous message (the one to which you are replying).

> quality

Huh?  I'm talking about IETF procedure.  Who I work for or what I'm
shepherding doesn't change that.

> there have been many calls to make a working group.

I think you should probably go back and read some of the archives of this
list from before you joined.  There was an attempt to create a working
group, and another attempt is probably appropriate.  Nobody is specifically
avoiding it; it's a matter of agreeing on a charter.

-MSK

---

From: "Popowycz, Alex" <[email-masked]>
Date: Fri, 6 Jun 2014 18:03:09 -0400

Vlatko

I suggest you remove the vitriol from your responses. Stating the messages that Vic referred to are unimportant is just such an example. Those messages are ones that individuals have opted-in to receive and are important to them. They may also be required as a matter of business, be they transaction notifications, fraud alerts and the like. I'm sure that individuals receiving those messages are better served with the actions to protect the email domain that Vic had undertaken.

Like many others who have successfully deployed DMARC, they've done so with the intent of maintaining the viability and integrity of the channel for their constituents.

My understanding (and general experience) is that this list is to move forward on a constructive path.

Email, as you well know has evolved in ways that we never envisioned when the underlying protocols were developed. However, the inherent lack of security has allowed for behaviors that have both positive and unfortunately increasingly negative uses and effects. Nowadays the vast majority of known major beaches originated with a malicious email. Like many protective solutions, both virtual and physical, there are often side effects. Take for example the automobile seat belt. One may find that it irritates the shoulder on long rides, but I for one accept that for the protection it provides. Like the seat belt, I can choose not to use DMARC, but I do so at my own peril.

-----Original Message-----
From: Vlatko Salaj [[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 06, 2014 05:21 PM Eastern Standard Time
To: Talamo, Victor
Cc: [email-masked]
Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out

'nuff said.

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

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 7 Jun 2014 00:10:13 +0200

> black hole called DMARC mailing list, for now.

You may be sorry, but you are not being excused.

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 07 Jun 2014 17:51:26 +0900

> Vlatko

Please don't feed the trolls (including me, I'm regretting my role
in this thread).  There's work to be done here, and Vlatko seems
uninterested in helping with it (eg, when asked for specific
references, he says "I'm not a search engine").

What I gather from Vlatko's posts is that there is a use case where an
entity (eg, a small business; called "ENTITY" below) wants its own
domain (called "OWNDOM" below) referenced in correspondence, but
prefers not to maintain a single presence (even as a VPS) on the
Internet.  Instead, ENTITY uses an ESP (below, "ESP" denotes
aparticular ESP) to send and receive mail, and ESP provides the usual
set of authentication services for its host.  The need is to provide
credentials and an authentication protocol for mailboxes in OWNDOM
that will satisfy identity alignment, and all actors will voluntarily
participate.

SPF would require that ESP permit ENTITY to specify MAIL FROM.[1]
Then ENTITY publishes an SPF record pointing to ESP's MXs and thus
provides identity alignment for OWNDOM.  However, this requires that
ESP trust that ENTITY has the right to use OWNDOM, and that may be
problematic.  Eg, spammers could sweep the DNS looking for SPF records
pointing to ESP and then specify a domain publishing such a record in
MAIL FROM.  Perhaps an additional protocol could be designed so that
registrars can vouch for entities (OAuth2?) but that's outside the
scope of this post.

DKIM seems to be easy, and requires no cooperation as long as ESP
passes mail through unchanged except for its own signature and trace
fields.  ENTITY just generates a keypair, publishes the public key
through its DNS, and DKIM signs its own messages with the private key.
This should be a SMOP (eg, Python has at least two packages on PyPI
for handling DKIM).  Identity alignment for OWNDOM will be satisfied.

An alternative would be for ENTITY to trust ESP a little bit, have ESP
generate the keypair, send the public key to ENTITY which publishes an
appropriate DKIM resource, and then the ESP DKIM signs for ENTITY (and
optionally for itself as well).  If this capability isn't available at
ESP, that too should be a SMOP (basically a database lookup to get the
key for ENTITY).  Identity alignment for OWNDOM will be satisfied.

This last approach seems like a business opportunity for ESPs.  Am I
missing something?

I don't understand why Vlatko thinks he has a problem that needs a
new protocol to solve.  What am I missing?

Footnotes: 
[1]  It's true that ENTITY could publish records in OWNDOM pointing to
the MXs as hosts (CNAME), but then HELO would be valid for any user of
ESP spoofing OWNDOM AFAICS.

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 7 Jun 2014 12:37:47 +0200

> new protocol to solve.  What am I missing?

I'm glad I'm not alone.

Regards,
J.Gomez

---

From: Franck Martin <[email-masked]>
Date: Sat, 7 Jun 2014 11:01:37 +0000

> that will satisfy identity alignment, and all actors will voluntarily

Stephen,

We (people with p=reject) went to all well known ESPs and asked them to send our emails with SPF and DKIM alignment with our domain. They all have been able to do it, tho some (especially account reps) did not know what DMARC meant :P

So I think requesting an ESP to do SPF and DKIM using your domain is not impossible, I think the issue, is a problem of scale at the moment. Few have “press a button” solution, and it is still a manual configuration, but I suspect, they will scale from manual to automatic setup to support any domain DMARC policies as more customers request the features.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 13:21:47 +0200

> So I think requesting an ESP to do SPF and DKIM using your domain is not impossible, I think the issue, is a problem of scale at the moment. Few have “press a button” solution, and it is still a ma…

Perhaps I am missing something basic, but I would think that the larger
barrier here is to make it easy for the domain owner to permit such
signing by third-parties.

To take an obvious example, [email-masked] wants to use
small-ESP for sending mail to small-business' customers.

How does small-business get Yahoo to readily delegate signing authority
to small-ESP?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Vlatko Salaj <[email-masked]>
Date: Sat, 7 Jun 2014 05:13:41 -0700 (PDT)

On Saturday, June 7, 2014 10:51 AM, Stephen J. Turnbull <[email-masked]> wrote:

> Please don't feed the trolls.

yeah, it was an interesting day yesterday.

i should have tried transmitting my posts with much better wording.

i sincerely apologize for any personal hurt i caused. i do not know
any of u, so any personal feelings towards u would be pretty
ungrounded, and i apologize for any i transmitted yesterday.

at least everybody here knows that i'm a knowledgeable person now,
and that they should thread carefully when discussing stuff with
me, or some shameless things may happen [until my posting
privileges get swashed away, at least, cause i'm threading on
edges always, i guess - the story of my life].

btw, if u r willing to contribute on a mailing list like this, it's
minimum decency to actually know what the hell u r talking about,
or even better, know draft documents to letter.

if a nobody like myself can do it, every list member can do it too.

...and before i start another flame war, let me move on.

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

---

From: "Popowycz, Alex" <[email-masked]>
Date: Sat, 7 Jun 2014 08:19:01 -0400

I think I may not be understanding the problem. In the situation cited by Dave, [email-masked] wants to have an ESP send mail on its behalf using the small business domain (i.e. FROM:@smallbusiness.com).

In that situation, why wouldn't small business get a DKIM key and unique selector and publish that in DNS, expanding the existing SPF record to include the relevant addresses of the ESP? In my experience, isolating that traffic using a subdomain (e.g. @esp.smallbusiness.com) for the from address would be preferred for operational and forensic purposes. The only role I can see Yahoo playing is taking responses to that traffic that originated from the ESP as indicated in the MX record for smallbusiness.com if that's what is desired.

-----Original Message-----
From: Dave Crocker [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 07, 2014 07:22 AM Eastern Standard Time
To: Franck Martin
Cc: Vlatko Salaj; Stephen J. Turnbull; DMARC Discussion; Popowycz, Alex; Talamo, Victor
Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out

d/

---

From: Douglas Otis <[email-masked]>
Date: Sat, 7 Jun 2014 05:23:51 -0700

On Jun 6, 2014, at 10:50 AM, Murray S. Kucherawy <[email-masked]> wrote:

> To answer Stephen's question, I'm guessing you're referring to ATPS (RFC 6541), use of CNAME to point to an externally-posted key, and a key exchange where an operator give a third party a signing key.  If there are others, I'd like to know what they are.
> 
> All three would require the Yahoo!s and AOLs of the world to grant signing keys, signing key aliases, or ATPS records to every domain that might re-send their mail.  There are some obvious issues with such solutions: (a) users will have to register every list to which they subscribe and wish to post; (b) they will have to automate DNS updates because every new entry into that registry will require a new DNS entry; and (c) if any of those third parties gets compromised, it's a big problem for the domain trying to protect itself.  If any bit of this fails (and I suspect (a) is actually the bigger problem), they don't work.

Dear Murray,

Unlike ATPS, TPA-Label does not expect users to register which lists they use.  TPA-Label avoids transparent authorization techniques such as the exchange of private key information which ensures all involved domains remain apparent.  Publishing public keys as belonging to a domain not controlling the corresponding private key puts that domain at unreasonable risk. 

Nor does TPA-Label require specific cooperation of third-party services.  Many of these third-party services are offered without renumeration.  Services involved can be obtained via DMARC feedback compared against lists of outbound domains.  ATPS created several unnecessary deployment problems not found in TPA-Label.  Updating the TPA-Label zone should be automated to better permit abuse mitigation.  For this feature, TPA-Label allows such zone generation to be maintained as a service by a different entity when needed.

DMARC seeks cooperation of receivers to assist in protecting their recipients by way of message rejection together with domain feedback for alignment failures.  Reject when appropriate has several advantages.  It helps retain the integrity of email delivery.  It clearly signals to the sender a message is not wanted which should escalate to a better review when frequent.  For such requests to remain honored, domains making DMARC requests MUST offer information that ensures:

1) Legitimate and compliant use of email is not disrupted.

2) Users' private exchanges being found in DMARC feedback is minimized to the greatest extent possible.  

3) At least Sender header fields should be able to offer alignments, perhaps by way of a TPA-Label specific exception.

To help improve the present state of trust, Original-Authentication-Results (OAR) will be added as an optional authorization requirement.  This option might help mend fences following events of abuse.

TPA-Label is akin to a highly extensible SPF based on validated domains rather than IP address lists.

Whether it is understood by those deploying DMARC, most mitigation of email abuse occurs as a result of automated zone generation.  TPA-Label has a significant advantage over that of real-time block lists, it unblocks.  As such, it should be less afflicted by DDoS attack.

Regards,
Douglas Otis

---

From: Vlatko Salaj <[email-masked]>
Date: Sat, 7 Jun 2014 05:25:03 -0700 (PDT)

> Internet.

nope. that's not what i want. i actually have a VPS for my personal
domain. its MTA forwards all my email to my yahoo account, which
i use to store, send, access from various places and ways and whatnow.
actually, most of my IT colleagues have something like this done
for themselves too. haven't we all?

the point is that i choose to trust a 3rd ESP for my email,
not my VPS provider. why? uhhh, many reasons, does it even matter?

as i said, it is my sole right to decide who i trust to
handle my email, and i want DMARC to upgrade itself to be able
to respect that.

anyway, what i propose is quite simple, pretty trivial
and easy to implement, actually:

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

it also covers much more than just my use case; it covers
use cases all falling into a group of DMARC 3rd party
alignment support, at least on a small scale.

actually, small scale support is what DMARC is lacking,
for most part. transactional email is all great and fine,
but most important email is one between real ppl,
and that part gets, in many use cases, excluded from
protection provided by DMARC in current alignment requirements.

while u can fix MLs with all those DMARC-compatible
workarounds, u still can't fix many use cases used by small
domains, which is, actually, most of the internet.

and my solution, being so easy, trivial, and quite simple to
implement, solves all of that.

also, it's easier than VBR, ATPS, TPA, TPA-Label, and moves
trouble of authorizing legitimate email from receivers'
error-prone, DMARC-policy-disrespecting, essential
whitelisting to domain-owner's control, where it should be.

and since DMARC provides reporting on domain's email flow,
domain-owners have everything they need to evaluate what
3rd party domains they would like to trust.

also, since DMARC 3rd party support remains specified
in their own DNS records, they have an easy and quick way
of dismissing any turned-malicious actor as soon as they like.

what u r proposing, Stephen, instead, is not at
all trivial or easy to implement, nor does it solve more
than just my special use case.

am i actually not advocating for it, cause it's rather
a completely different ESP service from what's common
practice now. is it better? maybe.
however, worth implementing? doubtful.

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 14:29:54 +0200

On 6/7/2014 2:19 PM, Popowycz, Alex wrote:
> I think I may not be understanding the problem. In the situation cited
> by Dave, [email-masked] wants to have an ESP send mail on its
> behalf using the small business domain (i.e. FROM:@smallbusiness.com).

Eyes and brains are such interesting creatures.  They have (minor pun) a
mind of their own.

What you cite is not what I specified.  I said [email-masked].

That's been their email address for years.  It is their online identity.
 These are /very/ small business folk with tiny revenues, no technical
skills, and a stable business.  There are quite a large number of them
in the world.

And they need the smallest disruption possible to the conduct of their
business life.

And in case anyone thinks that recommending switching to their own
domain name is "the" answer, that is a very, very long way from being a
small disruption for such folk.

That's why I cast the challenge of the situation in the way I original did.

d/

---

From: "Popowycz, Alex" <[email-masked]>
Date: Sat, 7 Jun 2014 08:48:58 -0400

Ahhh, OK. So no domain other than yahoo.com involved. I don't believe yahoo.com had set a subdomain policy so small business could have ESP send using @smallbusiness.yahoo.com with a reply to of yahoo.com, or simple send using the ESP's own domain with the same reply to as above? I know the first skirts the problem while the second doesn't address customers having white listed the original address. I'm just thinking practical "quick win" solutions and in no way trying to diminish challenges that a small business owner might face in these circumstances.

This is what happens when one has done idle time waiting in their car for their daughter to complete some AP tests...

-----Original Message-----
From: Dave Crocker [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 07, 2014 08:30 AM Eastern Standard Time
To: Popowycz, Alex
Cc: 'DMARC Discussion'
Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 14:54:38 +0200

On 6/7/2014 2:48 PM, Popowycz, Alex wrote:
> Ahhh, OK. So no domain other than yahoo.com involved. I don't believe
> yahoo.com had set a subdomain policy so small business could have ESP
> send using @smallbusiness.yahoo.com with a reply to of yahoo.com, or
> simple send using the ESP's own domain with the same reply to as above?

That would be a domain name change to the small business' online
identity.  Having Yahoo facilitate such a change might make the change a
slight bit more tolerable, but ultimately, such a change is a very big
deal for a very small business.

It's called "branding costs".  For small business, changing brand
information is extremely expensive.

> I know the first skirts the problem while the second doesn't address
> customers having white listed the original address. I'm just thinking
> practical "quick win" solutions and in no way trying to diminish
> challenges that a small business owner might face in these circumstances.

There is nothing quick or easy about the costs or effort in changing
one's brand.

> This is what happens when one has done idle time waiting in their car
> for their daughter to complete some AP tests...

There's probably a question about this on her test...

d/

---

From: Vlatko Salaj <[email-masked]>
Date: Sat, 7 Jun 2014 05:53:39 -0700 (PDT)

douglas,

i have seen ur work on TPA-Label ever since
ADSP, and i must admit, it looked complex
enough to cover almost anything.

but, its complexity is not working for u.
it seems to me that most of ppl r ignoring
ur posts, and TPA-Label completely.

maybe it would help if u had a working example,
beyond draft specs txt. especially since txt
isn't easy to digest.

so, maybe it would help to create some graphs
on its operations, and post them here, or
even a working website testing tool,
like Hector did with his proposal.

actually, maybe both of u should work together
into building something made from both of ur
proposals.

since i'm interested into adding 3rd party
support to DMARC, i would be willing to
help u two out.

truth be told, considering that majority of
DMARC developers don't care about our
3rd party requirements, having three separate
proposals with little support for each is
worse than getting one with a better support.

consolidation of our efforts may be more
fruitful.

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

---

From: Franck Martin <[email-masked]>
Date: Sat, 7 Jun 2014 14:37:06 +0000

Yahoo has been suggesting the ESPs use OAUTH, so the small business owner, can authorize the ESP to post on its behalf via yahoo servers… Not sure if it is today possible, but there is a bunch of apps that has been granted permission to post on Facebook, or Linkedin, or Google+

https://developer.yahoo.com/oauth/
https://developer.yahoo.com/mail/

I guess there was no need for ESP to do OAUTH, till now...

And yes, even for small business, it is best to have a brand, which is not yahoo.com. I suppose they have a website with their domain, tho for very small businesses, I would recommend just redirecting to their Facebook page...

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jun 2014 16:43:47 +0200

> I guess there was no need for ESP to do OAUTH, till now...

That might be an interesting line of capability to explore.

> And yes, even for small business, it is best to have a brand, which is not yahoo.com. I suppose they have a website with their domain, tho for very small businesses, I would recommend just redirect…

None of this helps the large and very installed base of on-going small
businesses.  And telling other businesses how to spend their scarce
resources is probably not our job.

On the average, things would always be better, if we did things in the
distant past that anticipated unexpected changes in the distant future.

d/

---

From: Vlatko Salaj <[email-masked]>
Date: Sat, 7 Jun 2014 08:02:08 -0700 (PDT)

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

consider this example of DMARC DNS record tags:

adkim=s:author-domain,s:yahoo.com,n:gmail.com
aspf=r:author-domain,r:yahoo.com,n:gmail.com

so, what i am proposing is changing adkim and aspf DMARC tags so
they become:

a comma-separated list of "alignment-strength:domain" pairs, in which

1. domains in colon pairs r 1st/3rd party domains author-domain
wants to align to or not,

2. default is "r:author-domain", similar to way it is now [relaxed],
and can be left out completely, or partly, on any colon side,

3. alignment-strength can be n, r or s [none, relaxed or strict],
which beside the usual relaxed and strict alignment policy, adds
possibility [n=none] to withheld alignment from a domain
[as a countermeasure against a newly discovered abuse].

the above example would read:

1. request strict dkim alignment for author-domain,

2. request strict dkim alignment for yahoo.com dkim signatures,

3. request dkim alignment failure for gmail.com dkim signature
[not rly needed if gmail.com isn't used for autor-domain's email,
but a useful thing to combat new abuse and remove trust from
previously trusted domain],

4. request relaxed spf alignment for author-domain and yahoo.com,

5. and finally, request spf alignment failure for gmail.com.
[same as 3.]

also, since relaxed and author-domain r defaults, we could do:
aspf=yahoo.com,n:gmail.com
instead of previous example, with same results.

even things like
adkim=yahoo.com,ymail.com,gmail.com,mybrosdomain.com
would be legitimate and would specify relaxed alignment policy
for all listed domains.

also, since i'm proposing a change on DMARCv1 tags, any such
change would essentially require DMARC advancing to v2,
but i consider this appropriate action, since it introduces
principal differences in how basic operations [alignment]
work in DMARC.

On Saturday, June 7, 2014 4:08 PM, Stephen J. Turnbull <[email-masked]> wrote:

> Unfortunately there's no protocol in there, you leave it implicit. :-(

look up.

> Unfortunately, AFAICS it doesn't address my needs (ie, MLMs), so I
> doubt I will be able to find time to work through it and figure out
> what you're suggesting in concrete terms.

on small scales, like 1-15 ML-domains, it can address those needs too.
be free to spend ur time on it, if u find it interesting enough,
and forget our hostility from yesterday. :D

sure, it won't fix yahoo's "p=reject", since yahoo will not publish
hundreds of ML-domains in their DMARC DNS record alignment list, but
it will fix other, smaller domains that use "p=reject".

>> to domain-owner's control, where it should be.
> I disagree with "where it should be".  The receiver has ultimate say
> on what messages it will accept, whether for relay to third parties or
> local delivery (or even "silent discard").

in respect to DMARC policy, author-domain should have control
over who posts email on its behalf. that was my point. receivers
should have nothing to do with that, no guesswork, in respect
to DMARC, but they r forced to do it now, going even as far to process
"p=reject" as "p=quarantine".

i'm not talking about receivers' anti-spam and other policies,
we r not in that mailing list. however, i do see DMARC used in
anti-spam filters too, in the future... with troubling results.

>> what u r proposing, Stephen, instead, is not at all trivial or easy
>> to implement,
> Define "trivial" and "easy." Asking the ESP to handle all
> of SPF, DKIM, and DMARC for mail purporting to be from your
> domain is an obvious solution

yeah, well i don't define trivial and easy like that. and i doubt
any ESP will introduce something like that. it essentially changes
the way they work now. i see no incentives for them to adapt to
these requests.

sure, i support them, be free to add my name to ur petition, but
i'm sure it's a waste of our efforts.

>> nor does it solve more than just my special use case.
> So what?

so, solution fragmentation. there r better solutions that cover
more stuff at once, without any 3rd party involvement, which is
preferential. it is also my principal viewpoint on life.

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

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 00:20:33 +0900

Vlatko Salaj writes:

 > > What I [== stephen] gather from Vlatko's posts is that there is a
 > > use case where an entity (eg, a small business; called "ENTITY"
 > > below) wants its own domain (called "OWNDOM" below) referenced in
 > > correspondence, but prefers not to maintain a single presence
 > > (even as a VPS) on the Internet.
 > 
 > nope.

OK, so it's not.  The solutions I propose still work if you have a
physical presence but *choose* not to use it to send mail, and Franck
Martin says that ESPs are open to cooperation as required by a subset
of those solutions.

The only difference is that there *may* be issues of spoofing or
losing mail that happens to be delivered directly from your personal
MTA.  I didn't want to make the effort to be *sure* so I chose a
setting where it wasn't an issue.

 > i want DMARC to upgrade itself to be able to respect that.

Please stop writing things like that.  It's either a semantic null or
a troll.  Somebody has to do the work, RFCs don't write themselves.
If you can't write a whole draft, at least write an outline of the
parts of the protocol your idea requires.

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

Now that's more like it!

Unfortunately there's no protocol in there, you leave it implicit. :-(
And you must have some new (undefined) forms of "alignment", as mail
"From: [email-masked]" can never satisfy DMARC identity
alignment with yahoo.com credentials.  Eg, what is being aligned" in
(2)?  Your "example" isn't a conforming DMARC record, in fact it even
usurps existing protocol (that's a no-no, even if a spec is only at
draft stage; it's not that hard to choose a new name, and adjust
nomenclature whan publishing a new draft).  Finally, the post is full
of minor inaccuracies, like writing "Sender-ID instead of SPF" when
Sender-ID depends on SPF.

 > what u r proposing, Stephen, instead, is not at all trivial or easy

Huh?  Define "trivial" and "easy."  Technically speaking, AFAICS DKIM
signing in the MUA is a SMOP (and in fact it can easily be done
outside of the MUA but on the same host as the MUA by a separate
application), many users with a personal domain can handle setting
DMARC and DKIM resources, and I see no reason why ESPs would alter the
signed portion of a message.

If the user *can't* handle setting those resources or your preferred
ESP insists on corrupting your messages, asking the ESP to handle all
of SPF, DKIM, and DMARC for mail purporting to be from your domain is
an obvious solution, and if the ESP goes rogue or has a security
breach compromising your private keys, you delete the authorizing
resources from your DNS.

 > nor does it solve more than just my special use case.

So what?  It's easy to implement and solves a use case that must be
fairly common out there.  Get real, man -- you're bitching *because*
it solves your use case?!

---

From: Terry Zink <[email-masked]>
Date: Sat, 7 Jun 2014 15:55:31 +0000

> We (people with p=reject) went to all well known ESPs 
> and asked them to send our emails with SPF and DKIM 
> alignment with our domain.

I did the same thing with microsoft.com (not every domain or brand at Microsoft, just microsoft.com). It took me six months. I'm going to be giving a talk about this at the Virus Bulletin conference in Seattle this September.

-- Terry

________________________________________
From: dmarc <[email-masked]> on behalf of Franck Martin <[email-masked]>
Sent: Saturday, June 07, 2014 4:01 AM
To: Stephen J. Turnbull
Cc: Vlatko Salaj; Popowycz, Alex; DMARC Discussion; Talamo,  Victor
Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out

Stephen,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Jun 2014 09:55:34 -0700

> worse than getting one with a better support.
I can't speak for anyone other than myself, but I'd bet that a third party
mechanism that scales and is relatively painless to add on would get proper
consideration.  So far none of the ones that have been proposed, including
my own, have gotten the necessary traction; that could be because they're
flawed, or they're not being communicated or demonstrated well, or a
combination of those.  That's not the same as "don't care", which I think
is an unfair and untrue claim.

> consolidation of our efforts may be more

I fully agree that's worth trying.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 02:17:10 +0900

> a comma-separated list of "alignment-strength:domain" pairs, in which

OK, I understand now.  This probably doesn't solve the mailing list
problem, especially since you'll run into the UDP size limit real fast
(your protocol will use a *lot* of octets for domain names), and I
doubt domains with a lot of wear and tear on their nameservers will be
happy about using TCP (my employer's nameservers don't accept TCP
queries from me, at least).

 > on small scales, like 1-15 ML-domains, it can address those needs

1-15 MLs?  I subscribe to about 30.  I think this is only going to be
useful for personal domains with 1-3 users, and even then there will
be many the way overtretch the practical bounds.

 > over who posts email on its behalf. that was my point.

But in reality it does not and never will.  It can't stop posting from
hosts outside of its control at all.  It can ask other domains to help
enforce its policy when they receive such messages, but they may not.
For a benign example, consider a honeypot feeding data about mail
abuse to a research project or a machine learning algorithm.

 > receivers should have nothing to do with that, no guesswork, in
 > respect to DMARC, but they r forced to do it now, going even as far
 > to process "p=reject" as "p=quarantine".

Nobody is *forced* to do any such thing.  Eg, Gmail *chooses* to treat
"p=reject" as advisory, we know that *some* messages that should be
rejected according to DMARC do get through to the recipient (at least
to the spam folder).  They do this not because they hate Yahoo!, but
because they think that is what will please their users without doing
Gmail any hard.  *This is as it should be.*

Other domains silently discard (my personal domain, which no longer
has any yahoo users among senders it wants to hear from), and I know a
few ML operators who have seriously considered doing the same even
though they do have posters from Yahoo! or AOL.

 > any ESP will introduce something like that.

Once again, you are not paying attention.  Franck Martin testifies
that he knows of many ESPs willing to make necessary adjustments, and
who are already doing so.

---

From: Franck Martin <[email-masked]>
Date: Sat, 7 Jun 2014 17:27:16 +0000

> That might be an interesting line of capability to explore.

Waiting for the first ESP that thinks it has a business case here.

> resources is probably not our job.

Well it is. the DMARC.org has a FAQ and the IETF (WG?) is writing a BCP. 

However I like to provide options. Solutions that work today, and solutions that work tomorrow.

Seriously getting a domain and getting yahoo to host it is not that expensive, I think USD10-35 a year…

https://smallbusiness.yahoo.com/email

It is just, nobody has written what exactly works in that path, and small businesses do not like to experiment. Anybody could provide some guidance here? A step by step transition guide?

> distant past that anticipated unexpected changes in the distant future.
Did you just watch X-Man: Days of future past?

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Jun 2014 13:35:25 -0400

Stephen, I hope the DMARC List moderators/chairs recognized your 
antagonistic "first strike" responses to concerned comments here. It 
isn't helpful.

This is a long time issue and I have been there since day one, since 
MARID when all these integrated design concepts and issues began. I 
don't recall your early participation in this but there is deep 
history in all this.  But thats ok. Welcome to the problem!! :) 
Generally people get involve when they begin to see something effect 
them.  It did with me in 2003 when the SORBIG infamous dual blitz (DoS 
RBL sites, Accept/Bounce attack the receivers) came and SMTP 
developers saw we finally needed to add something into our software to 
help operators.  Do you know what our first support answer was?  To 
enable their existing but optional SMTP feature:

     [_] Validate Local Recipient

You see, when people switched from UUCP/SLIP/UUCICO hosting methods to 
SMTP transports, the early versions do not have a RCPT TO validation 
process. So all mail was accepted and it was your existing internal 
import gateway that did the user delivery check. If not there, the 
mail gateway created a bounce to be sent out.  So the first support 
fix for very concern SORBIG suffering ESPs, ISPS, and all domains, was 
to tell them to enable the local user validate checks.

By doing this check at RCPT TO, you can potentially save 40% to 60% 
DNS overhead, wasted processing of all new DNS-based email security 
protocols. I have 11 years of consistent and persistent automated 
daily statistics recorded here:

      http://www.winserver.com/SpamStats

This has always been a basic client/server negotiated protocol 
engineer "lookup" discovery problem.

For DKIM, the solution was outlined in 9+ years of IETF work which 
does covers ALL client/servers situations. That was the goal. The 
feasibility of this was a concern and it depended on who it was 
applicable to.

But overall, it was about the dealing with the BAD, the GOOD and the 
UGLY.  Many administrators and list operators only wish to do deal 
with the good.  There is a long traditional to be "fail-safe", i.e 
accept all mail and let the user decide.  Thats been long understood 
but it only serves one part of the market needs.  Increasingly, the 
need for deterministic methods at the system level, not at the user 
level was becoming more apparent.  Again, as a SOFTWARE DEVELOPER, you 
have to cater to all market needs.

The IETF has to address two fundamental protocol engineering issues:

   LAYER #1: DKIM signature authorization protocol, and
   LAYER #2: DKIM signature trust/reputation protocol.

This was done in all the R&D, RFC work done. The threats, the 
optimizations, the expected short term overheads and redundancy issues 
were all considered.  In the short term, you should expect a high 
waste, high redundancy and network latency, performance issues with 
higher NXDOMAIN lookup results and early migration recommended paths 
of using relaxed Policies.   But in the long term with higher expected 
adoption, there would be some greater payoffs, efficacy, efficiency 
realized, especially as the domains migrated and got their network in 
order and began to switch over stronger policies.

This was ALL expected and it didn't begin with DKIM, it began with 
SPF.  It also had the same issues of scalability, network performance, 
nxdomain, relaxed vs strong policies design concerns.  But as expected 
and it took years for domains, but many did finally switch their SPF 
policy to the hardfail -ALL policy.

As it was predicted, we have the same dilemma with DKIM now. It is yet 
another philosophical, wasteful discussion on the merits having strong 
signature policies.  This concept has long been resolved by the 
market. It is a highly desirable feature and idea to be able to take 
control of your domain again.  As it was done with SPF, over time, the 
private domains, the higher value domains, began to use SPF -ALL 
policies, even the IETF is telling the world only their machines send 
out @ietf.org related mail:

     "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56
             ip4:64.170.98.0/24 ip6:2001:1890:126c::/56
             ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64
             ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64
             ip4:72.167.123.204 -all"

As you can understand, you technically do not need DMARC to process 
this SPF parameter and is highly inefficient with a high payload 
overhead if DMARC told implementators not to process SPF or wait until 
the DATA state is reaches in order to receive the 5322 payload 
overhead to get the Author Domain DMARC policy first to only to see 
if, for sure, the domain has a "p=reject."

Do you understand why the SUBMITTER protocol was invented for 
SENDER-ID?    Well, all these ideas apply because they all dealt with 
the same kind of 5321 vs 5322 implementation issues.   DMARC can have 
a similar optimizer for SPF:

    C: MAIL FROM:<[email-masked]> dmarc=(p=reject; ruf=dmarc-ruf);

This could tell the OPTIMIZED RECEIVER thats ok to reject before DATA 
is reached, even though the SPF -ALL already tells you its ok.  The 
"DMARC friendly" integrated difference is that it can tell the 
receiver to collect and send reports.

Etc, etc, etc.  The whole point, the IETF has long lost time in the 
entire DKIM+POLICY framework and its about time it gets serious about 
it (again).  Only with IETF endorsement will it begin to get wider 
adoption within the market. The IETF job's is to enable it.  Let them 
the implementations and deployments learn how to manage the DNS 
records and eventually come back and write a BCP for it or come up 
with a better DNS query concept.

Where do you end up with all this?  When do you actually begin to 
explore the proposed solutions that are technically sound?  There is 
software change cost. But the framework is sound.  Have you tried 
ADSP/ATPS or DMARC with ATPS updated for DMARC instead?

--
HLS

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 05:58:33 +0900

Hector Santos writes:

 > This is a long time issue and I have been there since day one,

I haven't participated in IETF discussions before.  But my personal
site was abused as an open relay in 1995 because Smail 100.something
advertised a no-relay config option but didn't implement it (so I had
to, while apologizing to a large number of pissed-off postmasters),
and I have a Zumabot T-Shirt.

 > Again, as a SOFTWARE DEVELOPER, you have to cater to all market
 > needs.

I disagree.  Software developers cater to the needs they want to,
including both pure good will and for-profit reasons for wanting to.

In this venue, many of us *want* to see protocols that work for
everybody all the time.  Me too.  However, as a MLM developer, I have
to say that in practice, the 9+ years of IETF engineering work has
dismally failed to achieve universal inclusion.  Both SPF and DKIM
marginalize mailing lists because they relegate them to world of
unauthenticatable traffic.  In practice, too, software developers
regularly fail to satisfy some of the market's needs.

Does that mean y'all owe us a pony?  It does not.  In today's
Internet, much as I hate to admit it, Mailman-style lists are a bit
marginal.  On the other hand, the Kucherawy-Crocker dkim-delegate
draft looks like a way forward for mailing lists, and I don't
understand why you and Vlatko feel the need to deprecate it in such
strong terms.

 > As it was predicted, we have the same dilemma with DKIM now. It is
 > yet another philosophical, wasteful discussion on the merits having
 > strong signature policies.

I don't have a problem with strong signatures.  I do have a problem
with the way existing protocols marginalize mailing lists.  I do have
a problem with the way DMARC "p=reject" can be abused and interfere
with mailing list traffic among other classes of email.  I think there
are valid reasons for worrying about the potential negative effects of
strong policies especially if they try to mandate rejecting mail
before the DATA transaction, and I disagree that:

 > This concept has long been resolved by the market. It is a highly
 > desirable feature and idea to be able to take control of your
 > domain again.

in the sense that as desirable as it may be, for the vast majority of
mailboxes, it probably cannot be implemented without losing a lot of
mail and perhaps having other unfortunate effects (eg, the thousands
of mailing list subscriptions that were disabled or even terminated
due to Yahoo! bounces).  And I doubt the average Yahoo! user would be
pleased to understand the full meaning of "control" as implied by that
domain's "p=reject" policy.

So AFAICS these "strong policies" remain as controversial as ever, and
progress is going to have to be made in small steps.  DMARC, IMHO, was
a remarkably big step by this criterion (but then, it has built on a
lot of experience of failed or marginal proposals).

 > As it was done with SPF, over time, the private domains, the higher
 > value domains, began to use SPF -ALL policies, even the IETF is
 > telling the world only their machines send out @ietf.org related
 > mail:
 > 

Sure.  I can't imagine why (except for fear of Murphy) anybody would
publish anything else.  (Well, actually I can, but I don't think that
discussion is particularly useful.)

What I don't agree with is using *only* the information about source
IP and SPF policy as a spam filter in a store and forward architecture
with mediators.  And I think this idea has been completely rejected by
the market (as opposed to blacklisting known spam source IPs, and
using SPF policy and source IP as one datum among several for
assessing abusiveness of a message).  Are there really sites out there
that reject on the basis of SPF -ALL without waiting for DATA?  I for
one could not use such a host.

 > is reached, even though the SPF -ALL already tells you its ok.

Well, no, in the real world SPF -ALL *doesn't* tell you that.  It
tells you that you can trust those hosts for traffic claiming to be
from the corresponding domain.  But you risk throwing away legitimate
messages if you reject just on the basis of that SPF record.  Even in
the bank case: I get a notice from my bank at home, but that account
is automatically resent (.forward) to my cellphone.  If my cellphone
provider bounces it because of SPF, I would be quite annoyed.  (DMARC
is a big improvement here, because it won't bounce due to DKIM
identity alignment.)

The fact is, with the exception of blacklisting truly evil hosts,
making a decision to reject based on the client's IP address and the
domain(s) in HELO and MAIL FROM is just a recipe for throwing away a
lot of legitimate mail and users in most domains will not stand for
it.

 > Only with IETF endorsement will it begin to get wider adoption
 > within the market.

DMARC proves that wrong.  What DMARC shows, AFAICS, is that what is
needed to get adoption in the market is a protocol that does what it
is designed to do *and* satisfies real needs.

Not to mention that in IETF tradition this whole sequence of
anti-mail-abuse standards is somewhat unseemly, as quite clearly many
were hopeful stabs in the dark based on a lot of theory and a little
bit of urgency, rather than codification of successful practice.[1]

 > Have you tried ADSP/ATPS or DMARC with ATPS updated for DMARC
 > instead?

Uh, no.  I'm interested in this discussion because I administer
mailing lists and develop MLM software, not MTAs.  So implementing
those protocols has not been a possible experiment for me.  I'm
working on getting control of the MTA for some of the public mailing
lists I administer, at which point I may experiment with it.  It's not
clear that the experiment would be very meaningful, though, as those
lists have very few Yahoo!/AOL subscribers, and none who have posted
from those domains in years.

In any case, ADSP is now historic, and it would appear to be
superseded by DMARC; I'm not sure what the point of trying ADSP is.

Footnotes: 
[1]  Granted, it's not just mail security standards that have moved to
adoption on the basis of theory, the whole IETF process is doing it.

---

From: Vlatko Salaj <[email-masked]>
Date: Sat, 7 Jun 2014 14:03:34 -0700 (PDT)

On Saturday, June 7, 2014 7:17 PM, Stephen J. Turnbull <[email-masked]> wrote:

> This probably doesn't solve the mailing list problem,

sure, it doesn't scale well to support more than a dozen domains, which
isn't a complete solution for mailing lists, but it can be used
in special cases when u have mailing lists that can't/won't adapt
to DMARC in any other possible or suggested way, and u can't
use any other developed workaround.

also, this whitelisting solution does fix quite a few other
use cases that DMARC without any 3rd party support simply
has to exclude. and most of those, if not all, r small scale
use cases, majority of worldwide scenarios.

actually, any proposed 3rd party alignment upgrade to DMARC would
do, imo.

what we need to agree upon is which is best overall. my proposal
may be quick, trivial, and simple... but Hector's proposal
is much more developed and opens wider support, and Douglas'
TPA-Label is rly complex but could fix almost anything and
everything.

and i may be missing some other proposal too.

also, there r DKIM-based upgrades to help workaround DMARC
deficiencies, however, imo, i would rather skip those, cause:

1. they don't fix SPF 3rd party alignment,
2. won't provide 3rd party alignment support out of box,
in case DMARC gets expanded to include another underlying protocol,
beside the SPF and DKIM,
3. r quite messy and seem unnatural.

> Nobody is *forced* to do any such thing.

they r "forced" by circumstances of DMARC having too much
false-positives with "p=reject". nobody wants unhappy users over
lost important email.

however, such practice essentially dismantles any strength DMARC has,
cause once services start treating reject as anything-but-not-reject,
it will become a common practice, and puff... away goes strong phishing
protection.

and then, it won't take long for phishers to understand what exactly
needs to be done to email to look like it should be treated as non-reject
by protocols at any receivers using such false-positives precautions.

that's where 3rd party support comes in. allowing domain-owner to
say: "trust here there like this and that, and don't trust anything
else", would dramatically ease upon any workarounds receivers need
to perform to keep DMARC false-positives as low as possible.

why? cause it will enable domain-owner to specify services it
considers more or less, but, trustworthy enough, to deliver its
mail.

> who are already doing so.

Franck isn't a representative of an ESP. i have full respect for
Franck ofc, but until i actually see an ESP publicly committing
to such a thing, it's all rumors.

and even if an ESP does such a thing, it doesn't mean it will
become a new common standard for all of them.

and even if it does become a new standard, it still doesn't preclude
actual 3rd party alignment support upgrade to DMARC, merely cause
3rd party support covers much more ground.

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

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 7 Jun 2014 23:35:20 +0200

On Saturday, June 07, 2014 10:58 PM [GMT+1=CET], Stephen J. Turnbull wrote:

> Are there really sites out there

Yes, there are.
 
Rejecting on the basis of SPF -ALL without waiting for DATA is cheap in resources, obeys the published policy of the sending domain owner, and affords the Recipient the benefit of off-loading the blame for the rejection onto the Sender.
 
Also, rejecting on the basis of SPF -ALL does not inconvenience at all mailing list traffic, as mailing list traffic usually takes ownership of the Return Path (envelope MAIL FROM), so if the mailing list host has an SPF record, its traffic will pass an SPF check without waiting for DATA.

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 08 Jun 2014 08:15:49 +0900

Vlatko Salaj writes:

 > sure, [my proposal] doesn't scale well to support more than a dozen
 > domains, which isn't a complete solution for mailing lists, but it
 > can be used in special cases when u have mailing lists that
 > can't/won't adapt to DMARC in any other possible or suggested way,
 > and u can't use any other developed workaround.
 > 

OK, I guess I'll have to take a closer look at the idea.

 > however, such practice essentially dismantles any strength DMARC
 > has, cause once services start treating reject as
 > anything-but-not-reject, it will become a common practice, and
 > puff... away goes strong phishing protection.

I think you dramatically underestimate the intelligence that will be
applied to this by the big mailbox providers.  First, the most
vulnerable domains and users (banks and their clients) are reasonably
easy to identify, and reject will continue to be treated as reject for
those Author Domains.  Second, use of "p=reject" by public mailbox
providers has so far been associated with security issues, and other
public mailbox providers (eg, Comcast) have made a point of
dissociating themselves from "p=reject".  It will be difficult for
them to adopt it -- unless they find themselves in a desperate
security situation like AOL and Yahoo! did.

 > considers more or less, but, trustworthy enough, to deliver its

I don't think it's that easy -- the domains that matter most are the
big public providers and ISPs.  The domain-based 3rd-party auth
schemes have a severe scaling problem in those cases.  I think the
dkim-delegate scheme actually is likely to scale better, and adapt
better to individual user needs.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 8 Jun 2014 00:56:47 +0100

> better to individual user needs.

Dear Stephen,

Considered how weak signing schemes can be abused, especially for small messages.  Short expiry offers little protection nor will capturing To: or Cc: headers or including BCC domains in the 'D' list. This solves a parochial interest and overlooks other serious issues. 

Email is only protected by assessing validated source domains.  Once a source is validated, a TPA-Label should allow the DMARC domain to grant needed alignment exceptions AND retract them when abused.  That is a feature missing in a DKIM delegation scheme that also seems likely to imperil safe use of BCC.  Frankly, DMARC already exposes those even merely receiving messages.  Nor will this scheme satisfy uses exemplified by services offered by Intuit.

It seems the greater good is to adopt a scheme able to handle any eventual abuse and encompasses all the issues.  If it is worth doing, it is worth doing right.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 07 Jun 2014 22:40:49 -0400

On June 7, 2014 5:35:20 PM EDT, "J. Gomez" <[email-masked]> wrote:
>Rejecting on the basis of SPF -ALL without waiting for DATA is cheap in
>resources, obeys the published policy of the sending domain owner, and
>affords the Recipient the benefit of off-loading the blame for the
>rejection onto the Sender.
> 
>Also, rejecting on the basis of SPF -ALL does not inconvenience at all
>mailing list traffic, as mailing list traffic usually takes ownership
>of the Return Path (envelope MAIL FROM), so if the mailing list host
>has an SPF record, its traffic will pass an SPF check without waiting
>for DATA.

I maintain a reasonably popular Postfix plugin for SPF checking that defaults to rejecting mail with an SPF fail result.  I think I've been doing it since 2007 and I don't recall ever having a complaint about this default (plenty of complaints and requests about other things).

I've published a -all SPF record since 2004.  I do occasionally have mail rejected due to forwarding. 

In my experience it's mostly smaller domains that reject on -all.

Personally, I prefer rejection over spam scoring. When it's rejected due to forwarding, the reject message always has the address I should send to directly in it.  If mail gets spamfoldered and the recipient never sees it, I never find out. 

No, it's not what the big guys do, but it's definitely done. 

Scott K

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2014 10:27:03 -0000

Dave Crocker  <[email-masked]> wrote:
>> Yahoo has been suggesting the ESPs use OAUTH, so the small business owner, can authorize
>the ESP to post on its behalf via yahoo servers… Not sure if it is today possible, but there
>is a bunch of apps that has been granted permission to post on Facebook, or Linkedin, or
>Google+
>> 

I doubt that Yahoo would be thrilled if ESPs used the Yahoo API to
send bulk mail.  I suppose the ESP could take the message, use the API
to send one copy of the message to itself so it gets Yahoo's DKIM
signature, then remail that message to all the subscribers through the
ESP's outgoing mail, sort of a virtuous replay attack.

This could probably work but it feels overclever, and doesn't scale
since no two mail providers have the same API.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Jun 2014 13:19:29 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Talamo, Victor
> Sent: Friday, June 06, 2014 4:56 PM
> To: Vlatko Salaj; Popowycz, Alex
> Cc: [email-masked]
> I concur with Alex.  Attached is very dated list of DMARC adopters from
> sometime last year and it is in no way comprehensive. The list is simply a
> sample to identify dmarc adopters, and included a mix of senders and
> receivers adopting DMARC. With that said if you check the DMARC records
> for these domains today, the vast majority of these domains are DMARC
> REJECT comprising billions of emails. Enough said.
> 

We implemented the essence of DMARC (the publishing of records in DNS didn't exist so I communicated to mailbox providers through the DKIM-ops list as well as directly) in late 2007, so my personal experience representing sending domains spans 6+ years and billions of emails.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Jun 2014 13:27:48 +0000

> Sent: Friday, June 06, 2014 5:19 PM
> To: Talamo, Victor
> Cc: [email-masked]
> > the vast majority of these domains are DMARC REJECT comprising
> > billions of emails.
> 
> billions of notification email. that barely anyone reads. and that nobody cares
> if gets lost.
> 
> i can only hope to see real data on number of DMARC false-positives in that
> billions of notification email, but i'm sure that would just completely crash
> any trust in DMARC, so we will never see it.
> 

Our analysis of DMARC reporting (AUF and RUF) plus private channel reporting for our domains indicates FP rates  ranging from .17% to .3% (that is, less than a fifth of a percent to a third of a percent). I'm not sure why you claim that reporting of FP rates would "completely crash any trust in DMARC, so we will never see it"?

> exactly the reason behind DMARC being an independent document on IETF.

Not really. While people who in the process (Attempt to bring DMARC under IETF auspices other than as an independent document) from both the IETF and DMARC sides may disagree on some things, I think all who were "in the room" would agree that the failure to do so was not a function of false positive rates.

---

From: Vlatko Salaj <[email-masked]>
Date: Mon, 9 Jun 2014 07:45:03 -0700 (PDT)

On Monday, June 9, 2014 3:28 PM, MH Michael Hammer (5304) <[email-masked]> wrote:

> FP rates ranging from .17% to .3%

so, in 1 000 000 000 of notifications, 1 700 000 to 3 000 000 is lost.
and u don't consider that a problem?

let imagine u have 333 333 customers. and u get a security breach.
and u decide to send instant security notice to customers by email asap.
and about 1000 customers possibly doesn't receive any such notice,
and about 560 of them doesn't get one for sure. and one of those 560 happens
to be a millionaire with a forwarding email account which serves his iphone.

well, if i were a bank, i would consider that a bad situation.

> I think all who were "in the room" would agree that
> the failure to do so was not a function of false positive rates.

actually, my point was that DMARC excludes too much of legitimate email,
not just false-positives.

but i guess it depends how u define too much.

not that it matters anyway. i'm somewhat sure any IETF DMARC work would
include 3rd party support, so imo, we have passed the point of no return,
and we r working to bring false positives down.

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 9 Jun 2014 15:52:25 +0000

> From: Vlatko Salaj [mailto:[email-masked]]
> Sent: Monday, June 09, 2014 10:45 AM
> To: MH Michael Hammer (5304); Talamo, Victor
> Cc: [email-masked]
> and about 1000 customers possibly doesn't receive any such notice, and
> about 560 of them doesn't get one for sure. and one of those 560 happens to
> be a millionaire with a forwarding email account which serves his iphone.
> 

Financial institutions can speak for themselves. I will point out that this is about tradeoffs rather than absolutes. The majority of false positives I see are because of forwarding on the recipient side. This is something the recipient can choose to address or not.It is beyond the control of the originator of the message.  For the financial institution the tradeoff is how many of their customers are getting phished or abused because of fake notifications (or similar) claiming to be from their domain which some significantly larger number (than the FPs caused by DMARC) of their customers are impacted by (as in theft of funds from their account). 

That is a worse situation - for both the customer and the financial institution. This is also why the financial institution asks for cellphone (SMS communication and/or voice), home phone and physical mailing address. If it is important enough then sending an email over the transom is not the way to ensure that the recipient gets the message. This has been an issue even absent SPF/DKIM/DMARC. 

> > I think all who were "in the room" would agree that the failure to do
> > so was not a function of false positive rates.
> 

Each domain, each user, each mailbox provider and each 3rd party service provider (for example MLs) will have a different definition based on their perspective, needs and desires.

> and we r working to bring false positives down.

I expect we will see solutions that will address various aspects of FPs. There will always be a certain amount of FPs that any reasonable person would expect. I have not seen much discussion of transient FPs where the validator is unable to look up the SPF or DKIM record. It does happen.