Subject: Re: [ietf-smtp] [dispatch] BCP proposal: regular expressions for Internet Mail identifiers

From: Sean Leonard <[email-masked]>
Date: Sat, 2 Apr 2016 02:57:10 -0300

Hello...

> On Mar 31, 2016, at 1:28 AM, [email-masked] wrote:
> 
> On Tue, 29 Mar 2016 15:38:59 -0400, John C Klensin said:
> 
>> Actually five families if you want to do a comprehensive job:
>> 
>> - 5321, possibly with nods to its predecessors
>> - 5322 which, as you point out, is not the same as 5321
>> 	(and most, if not all, of the differences are
>> 	intentional)
>> - the EAI family
>> - the base DNS spec family, as updated
> 
> And the corner cases when they don't agree. Consider
> [email-masked]  - how long did *that* wart get debated? :)
> 
> Those of us who were around for RFC1341 can look at the following,
> and weep, and ponder what failure modes the authors of this would have
> managed if they had *both* an ABNF and a regexp provided to work from,
> *even if they were semantically the same*...
> 
> % egrep 'X-Mail|alt' bad.mailfile
> X-Mailer: IBM Notes Release 9.0.1FP2 SHF37 August 25, 2014
> Content-Type: multipart/alternative; boundary="=_alternative  002EDD9148257F79_="
> --=_alternative 002EDD9148257F79_=
> --=_alternative 002EDD9148257F79_=
> --=_alternative 002EDD9148257F79_=--
> --=_alternative
> %
> 
> (Hint:  You'll probably need a fixed-space font and a lot of pondering - the
> above cost me close to 10 days of aggravation trying to figure out why one
> vendor's support emails were consistently getting eaten by my procmail
> filters, before I finally spotted it…)

Are you referring to the fact that the boundary has two spaces between “_alternative" and “002E...”?

Easy enough to spot. Not sure how that is germane to the topic at hand. I have not proposed writing standardized regular expressions for boundary parts; it is not clear why such a thing would be generally useful.

> 
> This is why we can't have nice things....
> 
> Oh, and those who want to tempt the Lovecraftian regexp elder gods should
> ponder the following:
> 
> http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
> 
> (If that doesn't make Sean reconsider, *nothing* will... :)

Does not make me reconsider at all.

<tongue-in-cheek>
Half the work is done, just copy-and-paste!
</tongue-in-cheeck>

A “deliverable” e-mail address is one that is deliverable with the modern SMTP infrastructure, i.e., that complies with the modern formulations of RFC 5321 (and RFC 6531, for EAI). That class of e-mail addresses is interesting, and much more straightforward to write a regular expression for.

The other ones are also interesting and will be covered. However, I would assume that non-mail processing implementers will want to focus on the modern RFC 5321-compliant expression(s).

Regards,

Sean

---

From: Ned Freed <[email-masked]>
Date: Fri, 01 Apr 2016 23:55:51 -0700 (PDT)

> Easy enough to spot.

Not sure how easy it is to spot by eye, but this is why msglint utilities
exist: So you don't have to. The one available at:

   https://github.com/NedFreed/msglint

spots the problem instantly. (You're also supposed to be able to run that one
from www.apps.ietf.org, but that's been down for a long time despite several
requests to update its IP address.)

> Not sure how that is germane to the topic at hand. I have not proposed writing
> standardized regular expressions for boundary parts; it is not clear why such a
> thing would be generally useful.

I don't see the relevance either.

> A “deliverable” e-mail address is one that is deliverable with the modern
> SMTP infrastructure, i.e., that complies with the modern formulations of RFC
> 5321 (and RFC 6531, for EAI). That class of e-mail addresses is interesting,
> and much more straightforward to write a regular expression for.

As a practical matter, there's lots of software out there that use bogus
regexps to check addresses. Anything that could possibly improve this situation
is a win in my book. And people have occasionally been known to look at RFCs
and use what they find there.

So unless someone can explain to me a likely scenario in which this going to
make the general situation worse, I support the adoption and publication of
this document.

> The other ones are also interesting and will be covered. However, I would
> assume that non-mail processing implementers will want to focus on the modern
> RFC 5321-compliant expression(s).

Personally, I'd settle for subaddresses working more than half the time with
web forms. I could not care less about support for obsolete syntax.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 2 Apr 2016 09:12:09 +0100

> and use what they find there.
...
> web forms. I could not care less about support for obsolete syntax.

This, +1, +100.

Arnt

---

From: Sean Leonard <[email-masked]>
Date: Sat, 2 Apr 2016 14:20:49 -0300

> On Apr 2, 2016, at 5:12 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> 

Yes, that was a major motivator for why I am proposing this work.

Not to wander on the topic to elsewhere: the presence of an address that contains + or some widely-used subaddressing character does not make it "the same" or equivalent in any way. Only the mail server can make that determination. I am firmly with John Levine and others in the mail camp on this topic. An implementation that sees user+one@ and user+two@, or user.one@ and userone@ really needs to treat these as distinct addresses, unless the implementation is the mail server itself, in which case, it can do whatever it is configured to do.

It should not be difficult to see that any difference in the local-part string can be used as a basis for differential routing, or not. Even if a mail server formally supports sub-addressing, a user or admin can choose (via Sieve scripts or otherwise) to route those messages to different places.

Sean

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 04 Apr 2016 17:10:47 -0400

> make the general situation worse, I support the adoption and publication of

Well said!

Dale