Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals

From: "John Levine" <[email-masked]>
Date: 17 Apr 2014 12:49:39 -0400

>      > 3. alignment domain-list value to include in alignment check:
>
>
> It doesn't scale as a complete solution for mailing lists. I don't see
> any scaling problem for the case of a domain used by a single entity
> that wants to authorize a few service providers to send email on its
> behalf.

Is that really a problem?  I was under the impression that a sender
either adds the providers' IPs to their SPF record, or gives them a DKIM
signing key.

This seems quite different from the mailing list problem, where it's
unlikely that it is practical to track exactly which lists its users
subscribe to.

R's,
John

---

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

> unlikely that it is practical to track exactly which lists its users

It's a problem if the service provider wants to offer bounce
processing by using their own domain for the return path, which I
think is not uncommon. That puts SPF out of alignment. Sharing a DKIM
key is a solution, but is not trivial.

The alignment domain-list solution seems trivial to me, and it works
without active support from the sender, which is nice.

Regards,
Joe Humphreys

---

From: John Sweet <[email-masked]>
Date: Thu, 17 Apr 2014 10:24:08 -0700

On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys <
[email-masked]> wrote:

> It's a problem if the service provider wants to offer bounce processing by
> using their own domain for the return path, which I think is not uncommon.
> That puts SPF out of alignment.
>

I think the difference is that the sender's domain can include the ISP's
ranges in their own SPF record. You can't reasonably do that for every
domain of every mailing list your users may post to.

The ISP rewrites the MAIL FROM to deflect bounces.  This passes SPF (IP
matches MAIL FROM), and also passes DMARC's aligned SPF (RFC822 From has
the original sender domain, which includes the ISP's IP range).

Please tell me what I'm missing.

J

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2014 15:04:45 -0400

> without active support from the sender, which is nice.

As I understand it, it requires a domain to enumerate every mailing list 
domain in which any of its users participate in its DMARC record. That's 
probably doable for a tiny domain like mine, but not for someone like Yahoo.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2014 15:08:33 -0400

> Please tell me what I'm missing.

A DMARC SPF pass requires that the MAIL FROM domain be the same as the 
From: header domain, or in less strict mode a subdomain.

The subdomain is probably doable, after considerable coordination 
between the sender and its ESP. The sender publishes MX records for the 
subdomain that point at the ESP's bounce handler.

---

From: Joseph Humphreys <[email-masked]>
Date: Thu, 17 Apr 2014 15:55:07 -0400

> probably doable for a tiny domain like mine, but not for someone like Yahoo.

Agreed -- I am absolutely not suggesting that this solves the mailing
list problem. I believe it does solve the bounce-processing ESP
problem, and the piggybacking on gmail problem. I also believe it's
easier to implement than delegated subdomains or 3d-party DKIM.

Regards,
Joe Humphreys

---

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

> without active support from the sender, which is nice.

How does it work without active support from the sender?  Doesn't the
sender first have to ensure it's in that list?  That's kind of an important
step for a list operator with a new subscriber from a "p=reject" domain.

-MSK

---

From: Joseph Humphreys <[email-masked]>
Date: Fri, 18 Apr 2014 13:04:08 -0400

On Fri, Apr 18, 2014 at 4:50 AM, Murray S. Kucherawy
<[email-masked]> wrote:
> How does it work without active support from the sender?  Doesn't the sender
> first have to ensure it's in that list?  That's kind of an important step
> for a list operator with a new subscriber from a "p=reject" domain.
>

Again, I have not been proposing this as a solution for mailing lists.
It solves at least two other problems: third-party bounce handlers,
and using your own domain with some large mail providers like gmail.
In either case, the domain owner can use DMARC without requiring any
support from the sender. This is not theoretical -- we have customers
who are currently stalled on DMARC implementations and who could move
forward if this were included in the spec.

If you are willing to accept additional DNS lookups, you actually
could use this to alleviate the mailing list problem, just by adding
an include syntax for aligned domain lists. That would create a
mechanism for people to make public, curated MLM whitelists. I
hesitate to bring that up because I imagine some people won't like the
idea of more DNS lookups, and I don't want the entire idea to get shot
down by association.

---

From: Franck Martin <[email-masked]>
Date: Fri, 18 Apr 2014 13:00:41 -0500 (CDT)

----- Original Message -----
> From: "Joseph Humphreys" <[email-masked]>
> To: [email-masked]
> Sent: Friday, April 18, 2014 10:04:08 AM
> Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals
> 
> > sender

Not delving in the details, but I may be off base...

It seems this solution is akin to have to add to your SPF record the whole of Google cloud or Salesforce cloud, with a "trust us" we don't allow any of our other members to send email on your behalf on any of our applications...

https://dmarcian.com/spf-survey/google.com 212,996 authorized individual IPv4 addresses
https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized individual IPv4 addresses

I prefer that 3rd parties relay our mail mail through our servers.

---

From: Joseph Humphreys <[email-masked]>
Date: Mon, 21 Apr 2014 12:01:16 -0400

> It seems this solution is akin to have to add to your SPF record the whole of Google cloud or Salesforce cloud, with a "trust us" we don't allow any of our other members to send email on your behal…

Yes, it is, unless the sender sets aside a more SPF-restricted domain
to use for sending customers' mail. In fact it is very similar to
including another organization's SPF record in your own, which does
not seem uncommon. That doesn't seem to me like a shocking level of
trust.

> I prefer that 3rd parties relay our mail mail through our servers.

That is eminently reasonable, considering that your organization sends
email as part of its core business, and is well prepared to take on
that responsibility. Obviously, there are a lot of organizations out
there who are not in that position.

So I think the question is, does adding an "aligned domains list"
feature encourage policies that are inherently unsafe? I would argue
that authorizing a service provider to send for you on all of their
IPs is not substantially different from authorizing them on one IP.
Once you've authorized someone to send mail on your behalf at all, you
are essentially trusting them to do it safely.

Regards,
Joe H

---

From: Franck Martin <[email-masked]>
Date: Mon, 21 Apr 2014 11:20:18 -0500 (CDT)

----- Original Message -----
> Sent: Monday, April 21, 2014 9:01:16 AM
> > It seems this solution is akin to have to add to your SPF record the whole
> > of Google cloud or Salesforce cloud, with a "trust us" we don't allow any
> > of our other members to send email on your behalf on any of our
> > applications...
> 

Yes indeed, but then, the recent breaches shows too much trust has been sprinkled all around. Many ESP will provide you with dedicated IPs for your sends, this allows you to control your deliverability, the email security, etc... They come at a price, but you have what you pay for.

> are essentially trusting them to do it safely.

I wish this would be that simple, more often than not, you are pushed into an agreement and can only negotiate mitigating factors as to lower the risk.