Subject: [ietf-822] EAI and ADSP/DMARC

From: Franck Martin <[email-masked]>
Date: Tue, 11 Sep 2012 23:59:19 +0000

I'm moving all the threads away from EAI last call, as I think I feel better with the current last call documents. I have been advised to also post to [email-masked]. So apologies, if I cross post and you miss a bit of history.

So I read RFC6530 and I'll try to resume my understanding.

No MTA talking to another MTA will downgrade or upgrade an email. If the receiving MTA cannot handle UTF8, then the email will be bounced.

Now the submitting MUA, will receive the bounce, and the MUA or the user may decide to provide an ASCII compatible email message, to be transmitted all the way. The RFCs do not seem to indicate specific ways to do a downgrade so that an International email can be converted into an ascii one and sent. It is left to the user may be with some help from its MUA to do this work.

However what I see is the possibility, for the MUA to use the group syntax in the From: header and submit that to the MTA to deliver to the final MTA.

If my understanding is correct, this is an issue because the receiving MTA will not have enough information to provide a check using ADSP or DMARC. This case should not be allowed.

That a receiving MTA downgrade the From: into a group syntax for the MUA to be able to display the email to the end user, is an annoyance in terms of ADSP/DMARC but as mentioned the fix is for the end user to upgrade its MUA. ADSP/DMARC would have already been applied to the email at this stage, so no core functionality would be lost in that transaction. The MTA would also have added Authentication-Results: header with the necessary information to indicate the result of SPF, DKIM, ADSP, DMARC. However this header is not easily visible to the end user. The DMARC spec can alert people about this case in Security Considerations, i.e. We could live with it.

So in summary, my opinion is that a submitting MUA MUST NOT be allowed to use the group syntax when submitting an email to an MTA. Corrolary a MTA MUST not accept an email where the From: header contains the group syntax and should bounce that email.

I think this course would keep the security benefits that ADSP/DMARC provide to the email environment.

Did I miss something?

This opinion is not the opinion of the DMARC group nor my company, etc… this is an individual submission as anything IETF related.

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2012 01:36:04 -0000

>Now the submitting MUA, will receive the bounce, and the MUA or the user may decide to provide
>an ASCII compatible email message, to be transmitted all the way. The RFCs do not seem to
>indicate specific ways to do a downgrade so that an International email can be converted into
>an ascii one and sent. It is left to the user may be with some help from its MUA to do this
>work.

That's deliberate.  The experimental predecessor to EAI tried to do
parallel EAI and ASCII addresses with automatic downgrade, and it was
an unworkable mess. See RFC 5504.

>However what I see is the possibility, for the MUA to use the group syntax in the From: header
>and submit that to the MTA to deliver to the final MTA.
>
>If my understanding is correct, this is an issue because the receiving MTA will not have
>enough information to provide a check using ADSP or DMARC. This case should not be allowed.

You can always reject mail you don't like.  ADSP is a failure, DMARC
will never apply to all mail.  We are not going to change the way that
mail works to make it match the security approach du jour.  That means
we're not going to make all mail DMARC-compatible any more than we got
rid of mail relays to make SPF happy.

If bad guys wanted to send mail with null groups on the From: line,
their spamware would be doing so right now.  What do you think will
change to make them start doing that in the future?  Surely nobody
imagines that spammers wait for the IETF to give them permission to
send stuff.  

Null groups on the From: line solve a specific EAI problem, and don't
enable any new evil that doesn't already exist in practice.

R's,
John

>Did I miss something?

Yes.

---

From: Franck Martin <[email-masked]>
Date: Wed, 12 Sep 2012 01:57:58 +0000

>rid of mail relays to make SPF happy.

Yes, I can always reject mail I don't like, but I doubt this will fly if
we add that in the DMARC spec and hand it over to IETF.

By the way the statement DMARC will never apply to all mail, is a bold
statment. Today it mainly applies to domains with a phishing problem, but
tomorrow? I don't see any limitations for DMARC to apply to all emails.

If I'm not mistaken, DMARC Filtering has been strictly implemented by
Google, Yahoo, AOL, Netease, XS4ALL, Facebook, LinkedinŠ These are lot of
protected mailboxes today. There is certainly a strong momentum for DMARC.

>imagines that spammers wait for the IETF to give them permission to

Just because today they don't have to, better techniques work for
spamming, does not mean they won't in the future.

The EAI group is changing the way the email standard has been defined for
exchanging email between MTA by allowing the group notation in the From:
header. I consider this change decreasing security not improving it.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 Sep 2012 08:55:44 -0400

> we add that in the DMARC spec and hand it over to IETF.

If/when DMARC comes into the IETF, you will have the same endless
arguments about that as in the DKIM/ADSP and SPF work about what who
can tell whom to do with messages and how.  John isn't saying that
*DMARC* will or should reject anything.  DMARC will simply say call
this a validation failure, just as it would if there were a fake From
address in the message.  John's saying that any MTA can choose to
reject such a message, because it doesn't like group syntax in From or
for any other reason.

There's already an applicability statement in here that says this is
for essential uses and no others, and there's a warning in the
Security Considerations that misuse can result in non-delivery of
mail.  What you're concerned about is already addressed.

Barry

---

From: Franck Martin <[email-masked]>
Date: Wed, 12 Sep 2012 18:17:13 +0000

>mail.  What you're concerned about is already addressed.

I think the impression is that DMARC is like the SPF -all or ADSP, just a
flag for the reputation engine down the stream.

A correct implementation of DMARC will reject emails at the edge as per
sender policies. This is very safe to do for the receiver because of all
the feedback mechanisms to the sender. Exceptions to the rule are also
documented in the feedback mechanisms.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 12 Sep 2012 20:37:20 +0200

On 09/12/2012 08:17 PM, Franck Martin wrote:
> sender policies.

You mentioned about ten big implementers. Are all correct in this 
regard? (Just curious.)

Arnt

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2012 19:46:47 -0000

>You mentioned about ten big implementers. Are all correct in this 

I think they all do the filtering in the SMTP session.  These days you
really want to reject the mail you don't want rather than sending
bounces, due to the blowback problem, so it's very common to do all of
the spam filtering at SMTP time.

The reasons to queue incoming mail and think about it later are a lot
less compelling now than they were in the 1980s or 1990s.

R's,
John

PS: This still doesn't mean that there's any reason to change your
mail system to do what DMARC wants unless you also want to.  It's
useful for protection against a narrow category of forged mail that
fakes famous domains, not very useful otherwise.  In particular, other
than the statistics gathering, it's useless for domains that have live
users who do typical live user stuff like forwarding their mail to
gmail and replying from there or using send-to-a-friend on a newspaper
web site.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 12 Sep 2012 13:03:11 -0700

"John Levine" <[email-masked]> writes:

> PS: This still doesn't mean that there's any reason to change your mail
> system to do what DMARC wants unless you also want to.  It's useful for
> protection against a narrow category of forged mail that fakes famous
> domains, not very useful otherwise.  In particular, other than the
> statistics gathering, it's useless for domains that have live users who
> do typical live user stuff like forwarding their mail to gmail and
> replying from there or using send-to-a-friend on a newspaper web site.

Like, for example, every higher-ed institution.

Few of the people who come on this mailing list with the new anti-spam or
anti-forgery or anti-whatever system du jour and that other uses of mail
really need to take their system into account realize that they have
dozens of predecessors who have, over the years, come on this list to say
exactly the same thing about many similar schemes.  Most of which no one
even remembers today.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2012 17:05:39 -0700

On 9/12/2012 12:46 PM, John Levine wrote:
> I think they all do the filtering in the SMTP session.

Given the DMARC sits on top of DKIM evaluation, the only place DMARC 
processing can be done during the SMTP session is after the DATA 
command.  No doubt, some/all of the major users of DMARC have put their 
code there, for the reason you cited.

That said, DMARC follows the usual model of making a distinction between 
giving a sending-side a means of expressing its desires, versus 
mandating what the receiving-side does with it.

In order to achieve protocol interoperability, a spec can dictate the 
behaviors of both sides.  Outside of that requirement, a receiver is not 
going to be "told" what to do by a sender.

The receiver might choose to pay attention to the receiver's wishes, but 
that's quite different from claiming that a failure to adhere to a 
sender wishes constitutes an "incorrect implementation."

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Sep 2012 18:44:09 -0700

> exactly the same thing about many similar schemes.  Most of which no one

    http://craphound.com/spamsolutions.txt

d/