Subject: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows)

From: José Ferreira <[email-masked]>
Date: Thu, 27 Nov 2014 11:34:57 +0000 (WET)

>From: "Franck Martin" <[email-masked]>
>Sent: Wednesday, November 26, 2014 10:29:35 PM
>
>Therefore it is important to read http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup SPF to work with >bounces.
>
>I know (or have known) several large properties that did not have this setup. Unfortunately, bounces are not very visible >and it is hard to stop sending emails to an invalid address if you cannot receive bounces due to policy.

So let's see how this must work in bounces ( DSN ):

Requirements:
 * For the domain, the RFC5321.EHLO/HELO domain is used if the RFC5321.MailFrom is null.
 * RFC5321.MailFrom must have a domain.
 * alignment must exits between RFC5321.MailFrom domain, SPF identifier domain and DKIM's d= value.

So a DMARC compliant DSN must:
 * Have a RFC5321.MailFrom with domain
 * Must present a HELO/EHLO hostname aligned  domain and/or DKIM sign with d= of the same domain.

Considerations:
 * This can be tricky in strict mode. Probably we should define a new specific field to define how this should align.
 * Some MTAs, at least Postfix, by default generate bounces with "From: MAILER-DAEMON (Mail Delivery System)".

Am I missing something  ?

Jose Borges Ferreira

---

From: Franck Martin <[email-masked]>
Date: Thu, 27 Nov 2014 13:35:23 -0600 (CST)

----- Original Message -----
> From: "José Ferreira" <[email-masked]>
> To: [email-masked]
> Sent: Thursday, November 27, 2014 3:34:57 AM
> Subject: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows)
> 
> >Therefore it is important to read
> >http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup SPF
> >to work with >bounces.
> >
> >I know (or have known) several large properties that did not have this
> >setup. Unfortunately, bounces are not very visible >and it is hard to stop
> >sending emails to an invalid address if you cannot receive bounces due to
> >policy.
> 
>  * This can be tricky in strict mode. Probably we should define a new
>  specific field to define how this should align.
RFC5321.From (envelope from) must be a valid email address or be null <>

RFC5322.From must have a domain (the From Header, not the envelope From RFC5321):
http://tools.ietf.org/html/rfc5322#section-3.6.2
http://tools.ietf.org/html/rfc5322#section-3.4

   from            =   "From:" mailbox-list CRLF

   mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list

   mailbox         =   name-addr / addr-spec

   name-addr       =   [display-name] angle-addr

   angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] /
                       obs-angle-addr

   addr-spec       =   local-part "@" domain

As such the construct you indicate is illegal:
From: MAILER-DAEMON (Mail Delivery System)

http://www.postfix.com/bounce.5.html, it is indeed a problem with postfix out of the box and empty_address_recipient needs to be configured properly.

Note: this rule for RFC5322.From may be relaxed by RFC6854 for EAI/SMTPUTF8 compatibility reasons only during the transition.

---

From: José Ferreira <[email-masked]>
Date: Fri, 28 Nov 2014 09:21:45 +0000 (WET)

----- Original Message -----
> To: "José Ferreira" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, November 27, 2014 7:35:23 PM
> Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows)
> 
> 
> >  * Must present a HELO/EHLO hostname aligned  domain and/or DKIM sign with
> >  d=
> >  of the same domain.
> > 
> > 
> > Considerations:
> http://www.postfix.com/bounce.5.html, it is indeed a problem with postfix out
> of the box and empty_address_recipient needs to be configured properly.
> 
> Note: this rule for RFC5322.From may be relaxed by RFC6854 for EAI/SMTPUTF8
> compatibility reasons only during the transition.
> 

I think there should be a wider reference to bounces in the draft-kucherawy-dmarc-base.
I know bounces are rare and we try the most to avoid bounces but it happens and have specific issues that should be addressed differently or , at least, highlighted.

José Borges Ferreira
AnubisNetworks

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 29 Nov 2014 15:22:13 +0900

José Ferreira writes:

 > I think there should be a wider reference to bounces in the
 > draft-kucherawy-dmarc-base.  I know bounces are rare and we try the
 > most to avoid bounces but it happens and have specific issues that
 > should be addressed differently or , at least, highlighted.

They are "rare" in the context of email in general, perhaps, but in
the case of mailing lists they aren't rare at all.  (Note, I don't
know if DMARC presents special issues for mailing list bounces, aside
from the bounces already produced because of subscribers whose MTAs
interpret "p=reject" as "return to apparent Sender".  I'm not talking
about the latter, which is already well-known.  I'm talking about
issues where a user cancels a mailbox, and the receiving MTA generates
bounces back to the list.)

---

From: José Ferreira <[email-masked]>
Date: Sat, 29 Nov 2014 12:04:21 +0000 (WET)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> Sent: Saturday, November 29, 2014 6:22:13 AM

I probably should call it DSNs.

The bounces you mention involve a third party ( the Ml or forwarder ) but I was referring to DSN generated by the domain owner. 
I'm talking about the scenario where you have a security gateway that accepts the email and them the message store reject it.This scenario the domain owner is not depending on the goodwill of others but only from himself.

Like is said, they are rare but important. And some domain owners may not adopt p=reject for that reason.  

Jose Borges Ferreira

---

From: Hector Santos <[email-masked]>
Date: Sun, 30 Nov 2014 10:42:13 -0500

> Like is said, they are rare but important. And some domain owners may not adopt p=reject for that reason.

Domains that publish a p=reject and don 't understand its possible 
outcomes, shouldn't be our (IETF protocol standards development) 
problem.  It helps to know they exist, but they should not be the 
reason for throwing out the proverbial baby out the window.

That is not to say strong, exclusive, restrictive domain policies do 
not have their place. I am on the side that more than most (pareto's 
principle) do know what they are doing and purposely set these 
policies and if there is an indirect flow issue, fortunately, it has 
been a minor issue to them.

The approach we (SSI) have taken since 2003 of implementing and 
deploying (and selling) strong ANTI-SPAM, SMTP REJECTION methods 
(meaning the PACKAGE OPTIONS were made available) is that:

      ONLY GOOD GUYS COMPLAIN, NOT BAD GUYS.

The bad guy does not pick up the phone crying to you about your 
rejection policies. So if the good guys complain which has been 
extremely and seriously rare (for SSI, i.e. low support 
cost/overhead), the easiest solution to to LEARN YOUR 
PERSONAL/BUSINESS NETWORK and white list them and/or if possible, 
technically correct whatever protocol issue their might be.  After 
all, all these protocols were really designed for the ANONYMOUS, 
UNSOLICITED TRANSACTION where A/A (Authentication/Authorization) HAS 
NOT been established.

   In order to be 100% backward compatible with SMTP Port 25 
operations, YOU MUST
   STILL support ANONYMOUS, UNSOLICITED TRANSACTIONS at the very least 
for NON-OPEN
   RELAY operations, i.e. for local users and locally hosted domains. 
   For Relays,
   A/A requirements kick in and that is what we are pretty much 
dealing with here.

But for the most part, MOST were bad guys and that is why these strong 
SMTP LEVEL rejection protocols do have a very high payoff for those 
that CAN deploy them.

We are not going to solve the mailing list problem UNTIL the mailing 
list folks (software developers) change their software TO SUPPORT 
Policy.  We still have people that are trying to avoid it, FOR 10 
YEARS, and that avoidance has not worked!

Its really that simple, however, the complete integrated solution is 
COMPLEX (and costly) and for the most part, only a total system 
integration can handle it.   If you (speaking in general) only have a 
MAILING LIST package, well, you need to wait for the other parts to 
fit in as well and vice versa.

All I reading (and it seems to be subsiding) are ML folks trying to 
advocate avoiding domains with strong, restrictive policies.  Well, 
can't have it both ways.  Intentional ignorance and expectation that 
things will continue to work and integrate well, is in my strong 
technical software engineering opinion, unrealistic.

All parts need to fit together and since its a multi-component 
integration problem, there are only a few packages that can do that. 
That is what makes this a long time difficult problem to solve.  You 
have systems people, operations, networks, mailing list people, etc 
and most have different goals and agendas.

-- 
HLS

---

From: José Ferreira <[email-masked]>
Date: Sun, 30 Nov 2014 19:58:32 +0000 (WET)

----- Original Message -----
> From: "Hector Santos" <[email-masked]>
> Sent: Sunday, November 30, 2014 3:42:13 PM

Forget about ML. I'm not only talking about ML but for a specific situation.

Let me detail the issue.

Most large system have several layers of defense. The edge system , after all teh checks, accepts the mail.
When trying to deliver to the message store, it bounces ( the common example is the mailbox full )!.

So the edge system generates a bounce message (MDN). Knowing that RFC5321.MailFrom will "<>".
To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the RFC5322.From of the MDN.

Again, this may be rare but should be referenced mainly because it can be easily overlooked. 

I guess I'm support Franck Martin when he wrote.

"I guess these two (sendmail and postfix) are the backbone of many appliances...

Therefore it is important to read http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup SPF to work with bounces."

and adding that the RFC5321.MailFrom must be aligned. For Postfix, changing the From in MDNs is not trivial but also not that complicated.

José Borges Ferreira.

---

From: Franck Martin <[email-masked]>
Date: Sun, 30 Nov 2014 16:35:36 -0600 (CST)

----- Original Message -----
> Sent: Friday, November 28, 2014 10:22:13 PM

Besides mailing lists, bounces are very important for large senders, marketing email companies, etc...

The usual rule is to stop emailing any email address that generated a hard bounce, but if you block such bounces due to the policy of the sender of the bounce... Well I guess they are going to be annoyed eventually and may not take the appropriate action, fix their bounces, and eventually block or limit the sender of the original message.

---

From: Franck Martin <[email-masked]>
Date: Sun, 30 Nov 2014 16:39:11 -0600 (CST)

----- Original Message -----
> To: "Hector Santos" <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, November 30, 2014 11:58:32 AM

> to work with bounces."
> and adding that the RFC5321.MailFrom must be aligned. For Postfix, changing
> the From in MDNs is not trivial but also not that complicated.
>  

It seems to me these things should go in a BCP or operational guidelines. 

DMARC relies on underlying layers to work properly and postfix package should be fixed, not sure what Wietse thinks about it.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2014 03:56:42 -0000

>To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the RFC5322.From of the MDN.

Why wouldn't you add a DKIM signature that matches the domain name in
the message From: line?  The envelope bounce return address is empty,
but the From: line isn't.

R's,
John

---

From: José Ferreira <[email-masked]>
Date: Mon, 1 Dec 2014 04:11:05 +0000 (WET)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: "jose ferreira" <[email-masked]>
> Sent: Monday, December 1, 2014 3:56:42 AM

That's is what I'm doing. 
Just pointing out that HELO must be aligned with From:. and in most cases it's not strict.

José Borges Ferreira

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 30 Nov 2014 23:20:30 -0500

On Monday, December 01, 2014 03:56:42 John Levine wrote:
> >So the edge system generates a bounce message (MDN). Knowing that
> >RFC5321.MailFrom will "<>". To be DMARC compliant the RFC5321.HELO/.EHLO
> >name must be align with the RFC5322.From of the MDN.

I think there was a missing "To get an SPF result that leads to a DMARC pass 
..." in there.  A DKIM signature will certainly do as well.

Scott K