Subject: [dispatch] BCP proposal: regular expressions for Internet Mail identifiers

From: Sean Leonard <[email-masked]>
Date: Tue, 22 Mar 2016 15:54:27 -0700

Greetings IETF-SMTP Gods and Denizens (and dispatch):

Over the winter I worked on a new Internet-Draft that I would like to 
propose the IETF adopts: Regular Expressions for Internet Mail. The 
draft focuses on two identifiers: email addresses and Message-IDs.

The purpose of this standard (proposed as a Best Current Practice) is to 
have *IETF-vetted* expressions that implementers and non-mail standards 
authors can plug-and-chug without futzing with trying to interpret 40 
years of (occasionally conflicting and arcane) RFCs and implementation 
lore. There are many non-mail systems out there (read: nearly every web 
app, reservation system, customer database, etc. on Earth) that use or 
consume email addresses as identifiers, and their inability to accept 
the most obvious valid characters (like "+" or even "-"; I have used 
apps that do not even accept "-") is a great source of interoperability 
problems. (This document is also relevant to some other threads about 
the nature of email address identifiers in security artifacts such as 
certificates, PGP keys, and DNS records: anyone who is vouching for an 
email address ought to be sure that they are recording something that 
actually is a valid email address in the first place.) We should get 
this right now, before Unicode/EAI makes interoperability issues 50000x 
more expensive to correct.

The document is not meant to modify the mail standards, but merely to 
reflect and track them as they are updated over time.

As a first draft, the document is in rough shape and has extensive notes 
about issues that came up during R&D but have yet to be addressed. 
Significant areas that need adequate treatment include:
1. the impact of Unicode (EAI) on identifiers.
2. handling domain names, which comprise 50% of an email address, but 
perhaps 85% of the complexity when Unicode gets involved.
2. "deliverable email address" (complying with the modern SMTP 
infrastructure) vs. other kinds of email addresses (Internet Message 
Format, historic forms).
3. regular expression engines and grammars (i.e., which grammars to use, 
which are widely used and produce uniform results).
4. efficiency of the regular expressions.
5. different expressions for validation (testing), part extraction 
(capturing groups), decoding, encoding, and searching through text.
6. test vectors.

Hopefully the adoption of this work as an IETF item, coupled with input 
from those with extensive experience

(Thanks to John Levine, Pete Resnick, and others for taking initial 
questions and discussion on the topic.)
Discussion welcome. Thanks.

Sean

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-seantek-mail-regexen-00.txt
Date: 	Mon, 21 Mar 2016 16:55:53 -0700
From: 	[email-masked]

A new version of I-D, draft-seantek-mail-regexen-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-mail-regexen
Revision:	00
Title:		Regular Expressions for Internet Mail
Document date:	2016-03-21
Group:		Individual Submission
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-seantek-mail-regexen-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-mail-regexen/
Htmlized:       https://tools.ietf.org/html/draft-seantek-mail-regexen-00

Abstract:
    Internet Mail identifiers are used ubiquitously throughout computing
    systems as building blocks of online identity. Unfortunately,
    incomplete understandings of the syntaxes of these identifiers has
    led to interoperability problems and poor user experiences. Many
    users use specific characters in their addresses that are not
    properly accepted on various systems. This document prescribes
    normative regular expression (regex) patterns for all Internet-
    connected systems to use when validating or parsing Internet Mail
    identifiers, with special attention to regular expressions that work
    with popular languages and platforms.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 23 Mar 2016 15:02:13 -0400

[I'm not sure why this was sent to Dispatch, as it doesn't seem to
involve SIP.]

As a work, this seems very useful, as it pulls together (or will pull
together) a lot of useful information about e-mail addresses in both
specification and practice.  But the terminology needs to be clarified
at some point:  a single document (or sentence) is either normative or
not.  If something is a "best common practice", it is not normative, the
rules are set somewhere else.

Dale

---

From: Adam Roach <[email-masked]>
Date: Wed, 23 Mar 2016 14:06:01 -0500

> [I'm not sure why this was sent to Dispatch, as it doesn't seem to

DISPATCH is area-wide. With the merging of APPS and RAI to form ART, 
you're going to see DISPATCH being asked to handle topics that would 
have traditionally been part of APPS' purview.

/a

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Mar 2016 14:37:05 -0500

> have traditionally been part of APPS' purview.

Adam beat me to it. We are all ART now :-)

There's even a new charter: 
https://datatracker.ietf.org/wg/dispatch/charter/

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Mar 2016 15:38:46 -0400

> [I'm not sure why this was sent to Dispatch, as it doesn't seem to

dispatch is being rechartered to have scope encompassing all of the ART 
area. I *think* this proposal falls in that scope.

	Thanks,
	Paul

---

From: Sean Leonard <[email-masked]>
Date: Wed, 23 Mar 2016 14:27:46 -0700

On 3/23/2016 12:02 PM, Dale R. Worley wrote:
> specification and practice.

Great!

>    But the terminology needs to be clarified

IETF Process issue:
Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. 
However, it is referred to normatively by a slew of Standards Track 
documents. I would propose that this document be seen in a similar 
light. One would not expect the Mail Standards to adopt these regular 
expressions, but other standards that use regular expressions for e-mail 
would probably do best to refer to this document. Examples include 
CBOR/CDDL (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records 
(RFCs 3401-3404), when the subject matter is e-mail stuff.

When I raised the classification issue during initial development, one 
advisor said something to the effect of oh, so it's like a Real BCP, 
where it actually prescribes actual Best Current Practices, unlike what 
most of the BCPs these days are. (Whatever that means, just the messenger!)

Sean

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Mar 2016 17:32:37 -0400

BCPs can be normative, Dale.   It's informational docs that are not.   They
are "informative."   :)

On Wed, Mar 23, 2016 at 5:27 PM, Sean Leonard <[email-masked]> wrote:

> Well, RFC 5646/BCP 47 "Tags for Identifying Languages" is a BCP. However,
> it is referred to normatively by a slew of Standards Track documents. I
> would propose that this document be seen in a similar light. One would not
> expect the Mail Standards to adopt these regular expressions, but other
> standards that use regular expressions for e-mail would probably do best to
> refer to this document. Examples include CBOR/CDDL
> (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records (RFCs
> 3401-3404), when the subject matter is e-mail stuff.
>
> advisor said something to the effect of oh, so it's like a Real BCP, where
> it actually prescribes actual Best Current Practices, unlike what most of
> the BCPs these days are. (Whatever that means, just the messenger!)
>
> Sean
>
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Mar 2016 21:02:36 -0500

On 23 Mar 2016, at 14:38, Paul Kyzivat wrote:

> dispatch is being rechartered to have scope encompassing all of the 
> ART area. I *think* this proposal falls in that scope.

For the record, it _has_been_ rechartered. (Otherwise, I agree.)

Ben.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Mar 2016 10:15:44 +0000

Hi Dale,

> On 23 Mar 2016, at 19:02, Dale R. Worley <[email-masked]> wrote:
> 

Dispatch is now ART-area-wide, so other ART topics can be brought here.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 27 Mar 2016 22:29:37 -0700

> area. I *think* this proposal falls in that scope.

(Just to make it somewhat official)  This is correct.

-MSK, DISPATCH co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 27 Mar 2016 22:41:02 -0700

> 3401-3404), when the subject matter is e-mail stuff.

It seems to me RFC2026's definition of BCP would cover what you're trying
to do here.

And if what you're really producing is regular expressions that match
anything that the ABNFs in the mail RFCs will legitimately produce, you
might want to do a standards track document that explicitly updates those
documents where those ABNFs are listed.

Then again, I could see this just as easily going Informational since it's
unlikely (to me, at least) that anyone will point compliance language at
such a document.

How's that for actionable feedback?  :-/

-MSK

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Mar 2016 09:18:58 -0400

--On Sunday, March 27, 2016 22:41 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>...
> And if what you're really producing is regular expressions
> that match anything that the ABNFs in the mail RFCs will
> legitimately produce, you might want to do a standards track
> document that explicitly updates those documents where those
> ABNFs are listed.

Murray,

That captures my concern about this effort.  Based on prior
experience (including RFC RFC 3696 and even the effort to make
RFCs 2821 and 5321 internally consistent), it is _really_ easy
to express a requirement in two different ways and have them be
_almost_ the same.   That is a problem because different people
will read different docs.  

It seems to me that it would be much better to either do this as
an Informational document that is clearly identified as Sean's
opinion about regular expressions that impose the same
requirements as 5321/5322 but that those continue to control or
to do a standards-track document that contains both the regular
expressions and ABNF, makes clear which one is primary, and
updates the syntax requirements of the base specs.

Perhaps a BCP that recommends use of strings that are clearly a
proper subset of what the standard allows would be ok, but it
needs to be frightfully clear that it is a recommended subset,
not a requirement.  For example, I've seen enough problems with
the two quoting conventions over the years that I'd be delighted
to see them eliminated entirely.  On the other hand, I've seen
one attempt after another (outside the IETF) to reduce the rules
to simple regular expressions or equivalent that would forbid
subaddresses and/or the required syntax for conversions of
addresses from some other systems (the X.400 stuff stands out,
even though very few people care about it any more).

best.
    john

---

From: Sean Leonard <[email-masked]>
Date: Mon, 28 Mar 2016 17:21:23 -0700

On 3/27/2016 10:41 PM, Murray S. Kucherawy wrote:
> On Wed, Mar 23, 2016 at 2:27 PM, Sean Leonard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     However, it is referred to normatively by a slew of Standards
>     Track documents. I would propose that this document be seen in a
>     similar light. One would not expect the Mail Standards to adopt
>     these regular expressions, but other standards that use regular
>     expressions for e-mail would probably do best to refer to this
>     document. Examples include CBOR/CDDL
>     (draft-greevenbosch-appsawg-cbor-cddl), and DNS/NAPTR records
> It seems to me RFC2026's definition of BCP would cover what you're 
> trying to do here.
>
> anything that the ABNFs in the mail RFCs will legitimately produce, 
> you might want to do a standards track document that explicitly 
> updates those documents where those ABNFs are listed.

BCP or Standards Track are fine by me.

>
> Then again, I could see this just as easily going Informational since 
> it's unlikely (to me, at least) that anyone will point compliance 
> language at such a document.

They said that for RFC 4627, too. :)

I will make this easy: not going to pursue Informational status. I 
foresee compliance language referring to these regular expressions: if 
not in the IETF, then in other bodies. Any software library that has 
Internet + regular expression capabilities, would be an example. 
Consider, for example, the POSIX standard, and the C++ standard library 
standards. It would be reasonable for web browers/ECMAScript/HTML/DOM to 
offer e-mail address validation capabilities at some point in the 
future, with polyfill to fill in older implementations.

Oh wait, they already do that...and badly:
https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email)

BCP seems like the best choice.

Sean

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Mar 2016 17:56:59 -0700

On Mon, Mar 28, 2016 at 5:21 PM, Sean Leonard <[email-masked]> wrote:

> I will make this easy: not going to pursue Informational status. I foresee
> compliance language referring to these regular expressions: if not in the
> IETF, then in other bodies. Any software library that has Internet +
> regular expression capabilities, would be an example. Consider, for
> example, the POSIX standard, and the C++ standard library standards. It
> would be reasonable for web browers/ECMAScript/HTML/DOM to offer e-mail
> address validation capabilities at some point in the future, with polyfill
> to fill in older implementations.
>

John Klensin makes a compelling argument that this stuff should actually
not be published in a way that's equally normative with the existing
standards track documents.  I wonder if that compels it in the
Informational direction.

Your choice of publication status will require some amount of consensus, so
your assertion might be premature... ;-)

-MSK

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 29 Mar 2016 11:45:09 -0400

> most of the BCPs these days are. (Whatever that means, just the messenger!)

In re Dispatch, I knew that its scope had been broadened, but had
forgotten that.

In re "BCP", the reference is RFC 2026 section 5, "The Internet
Standards Process -- Revision 3" ... which is itself a BCP.  What it
says is that BCPs are *standards* not for protocols but for *things that
people do*.  So in regard to your draft, the "thing that people do" is
"write code that validates e-mail addresses for further processing".
And the point of your draft is that people need to write correct code
for validating e-mail addresses.

Here's another ugly little bit of processing:  On some systems, library
routines that convert dotted-number IP address strings into four-octet
format treat a component that starts with "0" as being written in octal.
E.g., "010.010.010.010" is equivalent to "8.8.8.8".  (Try executing "dig
ietf.org @010.010.010.010" on a Linux system.)  As far as I know, this
isn't *specified* anywhere in the RFCs, and some RFCs (e.g., RFC 997)
have leading zeros on numbers that contain "9".  So it's worth warning
people not to use leading zeros in IPv4 addresses.

I can see a lot of value in cleaning up this mess.  If it's possible to
not make (many) systems stop working, it would be worth making the new
version normatively update the existing specs.

Dale

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Mar 2016 12:28:14 -0400

--On Tuesday, March 29, 2016 11:45 -0400 "Dale R. Worley"
<[email-masked]> wrote:

>...
> Here's another ugly little bit of processing:  On some
> systems, library routines that convert dotted-number IP
> address strings into four-octet format treat a component that
> starts with "0" as being written in octal. E.g.,
> "010.010.010.010" is equivalent to "8.8.8.8".  (Try executing
> "dig ietf.org @010.010.010.010" on a Linux system.)  As far as
> I know, this isn't *specified* anywhere in the RFCs, and some
> RFCs (e.g., RFC 997) have leading zeros on numbers that
> contain "9".  So it's worth warning people not to use leading
> zeros in IPv4 addresses.

And that comment identifies another ugly little issue.  An email
address of [email-masked] implies that
"010.010.010.010" is a domain name and "010" (the rightmost
label) is a TLD.   Because there is no such TLD (nor is there
one for "8."), such an address is an error, so, if a
mail-related regular expression document pursues that question
at all, it would allow something that violated 5321 no matter
whether 010 is interpreted as "2", "8", "10", "16", STX,
Backspace, DLE, or something else.

I'm not suggesting Sean would do that, only emphasizing (again)
the dangers of developing a second spec (or two specs more
generally) that is inadvertently not quite consistent with the
other one.

    john

---

From: Sean Leonard <[email-masked]>
Date: Tue, 29 Mar 2016 11:12:04 -0700

> updates the syntax requirements of the base specs.

As Dale expressed (thanks!), "BCPs are *standards* not for protocols but 
for *things that people do*. So in regard to 
[draft-seantek-mail-regexen], the "thing that people do" is "write code 
that validates e-mail addresses for further processing". And the point 
[...] is that people need to write correct code for validating e-mail 
addresses."

Sean's opinion about regular expressions for Mail Identifiers (email 
addresses, Message-IDs) is not interesting. If my opinion were all that 
interesting, I would just publish it on Stack Overflow and call it a day 
(see SO Questions [46155] and [201323]). What is interesting is the 
IETF's vetted and (rough)-consensus view on the topic.

This topic is a favorite pet project of programmers. It tends to go:
1) "oh, I know what an email address is! It has dots and alphas and 
maybe a hyphen" (WRONG),
2) "oh, I'll just read RFC 5322 and roll my own" (also wrong, but in 
more subtle ways...for one, RFC 5322 has distinct syntax from RFC 5321), or
3) "I'm lazy, let's just copy whatever regex shows up on Google first" 
(pragmatic, usually not right).

Wouldn't it be better if programmers could uniformly go:
4) "Given my email address recognition problem, I'll just copy the regex 
from BCP xyz", rather than spending dozens if not hundreds of hours 
pouring over email standards documents and testing them against millions 
of arcane email address combinations.

The current draft-seantek-mail-regexen is pretty clear (currently) that 
it does not attempt to change the Mail standards. If folks want to 
change those documents, may I suggest a separate Standards Track 
document that does exactly that.

Just because a document is labeled "BCP" (or, for that matter, 
"Standards Track") does not mean that every last single statement in the 
document is normative and error-free. Otherwise, the RFC 3280 and RFC 
5280 PKIX standards that say that you are supposed to compare an entire 
email address case-insensitively (Section 4.1.2.6 of RFC 3280, Section 
4.2.1.6 of RFC 5280) would have overridden RFCs 5322, 5321, 2822, RFC 
2821, etc. etc. We have an errata process.

Basically if the regular expressions are wrong, they need to be made 
right. One can complain about problems, or one can fix them.

Turns out that regular expressions and ABNF are homomorphic under 
certain conditions. As shown in draft-seantek-mail-regexen, "deliverable 
email addresses" (RFC 5321 + RFC 6531) certainly fall in that 
definition, as they can be expressed in a regular language (i.e., 
computed with a finite state automaton). Therefore, translating between 
the two is basically computationally verifiable. The results may not 
look pretty but they will work. Perhaps a bigger problem is one's view 
as to how normative ABNF is in the context of IETF standards documents. 
It is possible to have ABNF that says somename = *(ALPHA / DIGIT) but 
then have normative text that says that <somename> is limited to 31 
characters and MUST start with an alphabetic character. Moreover, some 
ABNF (RFC 5321 / RFC 5322 in particular) have "obsolete syntax"; whether 
to admit such syntax is a highly context-sensitive engineering decision. 
Addressing all of these points requires rubbing more than two brain 
cells together.

[46155]: 
http://stackoverflow.com/questions/46155/validate-email-address-in-javascript
[201323]: 
http://stackoverflow.com/questions/201323/using-a-regular-expression-to-validate-an-email-address

> not a requirement.

I am not really interested in subsets, except those subsets driven by 
the standards themselves. (ASCII-only vs. EAI is a reasonable subset, 
provided that both expressions are provided. I would rather do EAI-only 
but we can be pragmatic about that.)

Best regards,

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 29 Mar 2016 11:31:36 -0700

On 3/29/2016 9:28 AM, John C Klensin wrote:
> I'm not suggesting Sean would do that,

Covered that already. ;-) See the pattern "restricts out all-numeric 
labels [RFC1912]" in Section 3.1.3.

I hope that this does go to show that raw/blind application of the ABNF 
in RFC 5321/5322 is not sufficient.

>   only emphasizing (again)

The danger is real, and noting it is appreciated. It's worth considering 
that we are not talking about one spec, but two families of specs (the 
email specs and the DNS specs) that we need to summarize and put together.

It turns out that the domain part is 50% of an email address but 
generates perhaps 85% of the complexity. The quoting rules for 
local-part are arcane but at least are fairly systematic. There is a 
question about how much it's the responsibility of an "email address 
validator" to validate the domain part.

I do not wish to answer this question in isolation. On the one hand, 
it's usually a DNS library's "job" to answer that (not an email library 
per-se); on the other hand, if it's not a good domain name, the email 
address is literally pointing to an imaginary place. The answer is, I 
suppose, "it depends" and the Best Current Practice is to document the 
issue so qualified engineers can make sound judgments about what to do. 
I would analogize this to a US Postal Service validator, validating 
two-letter state-and-political-division abbreviations. Every 
state-or-political-division has a two-character alphanumeric code: 
enforcing the two-character requirement and the alphabetic requirement 
in a validator would be separately reasonable if the relevant USPS 
standards promise the same. However, avoiding repeated characters (AA, 
BB, CC) seems to be more of a registration practice/requirement, so a 
validator need not impose such a requirement if the relevant standards 
do not call for it.

Regards,

Sean

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Mar 2016 15:38:59 -0400

--On Tuesday, March 29, 2016 11:31 -0700 Sean Leonard
<[email-masked]> wrote:

>...
> I hope that this does go to show that raw/blind application of
> the ABNF in RFC 5321/5322 is not sufficient.

Sorry, but the ABNF in 5321/2821 and the BNF in 821 have _never_
been sufficient to define the grammar in complete and closed
form.  It sets some structure and bounds on the grammar, but the
prose explanations and details are at least as important.  If
you don't think the RFC makes that clear, please file an erratum
-- it might even motivate me to take 5321bis out of long-term
storage (although that is definitely not a promise -- the
aggravation costs are provably very high).

>...
> The danger is real, and noting it is appreciated. It's worth
> considering that we are not talking about one spec, but two
> families of specs (the email specs and the DNS specs) that we
> need to summarize and put together.

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
 - the IDNA family (2003, 2008, and maybe assorted
	mapping and deviant (i.e., encouraging something that
	violates IDNA2008)
 
> It turns out that the domain part is 50% of an email address
> but generates perhaps 85% of the complexity. The quoting rules
> for local-part are arcane but at least are fairly systematic.
> There is a question about how much it's the responsibility of
> an "email address validator" to validate the domain part.

If one believes in IDNA2008 --which there is some obligation to
do until it is replaced or deprecated-- then there are actually
some very clear validation rules.

> I do not wish to answer this question in isolation. On the one
> hand, it's usually a DNS library's "job" to answer that (not
> an email library per-se); on the other hand, if it's not a
> good domain name, the email address is literally pointing to
> an imaginary place. The answer is, I suppose, "it depends" and
> the Best Current Practice is to document the issue so
> qualified engineers can make sound judgments about what to do.
> I would analogize this to a US Postal Service validator,
> validating two-letter state-and-political-division
> abbreviations. Every state-or-political-division has a
> two-character alphanumeric code: enforcing the two-character
> requirement and the alphabetic requirement in a validator
> would be separately reasonable if the relevant USPS standards
> promise the same. However, avoiding repeated characters (AA,
> BB, CC) seems to be more of a registration
> practice/requirement, so a validator need not impose such a
> requirement if the relevant standards do not call for it.

Right.  And that isn't actually a common practice at the second
or third level or below in most domains.  There, within other
constraints that are documented, the rule tends to be either
"you get whatever you want and can pay for" or "you get whatever
you can convince the zone admin is reasonable".

best,
    john

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 30 Mar 2016 19:07:48 +0900

> https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email)

Just to connect some dots, there's a discussion with respect to HTML and 
EAI addresses at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15489.

Regards,   Martin.

---

From: [email-masked]
Date: Thu, 31 Mar 2016 00:28:57 -0400

>  - 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...)

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... :)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 30 Mar 2016 18:47:04 +0200

A document does not need to define a syntax in order to be useful.

For 
instance, a document containing sections such as this could be good and 
useful: "The following regexp allows all classic email addresses and 
disallows many common typing mistakes...", ditto EAI, and with 
descriptions of their shortcomings.

I am not sure whether something 
that matches a subset of valid addresses could be useful. 
Perhaps.

Arnt