Re: [ietf-smtp] Valid RFC5322 address

[John C Klensin <[e-mail]>]

--On Sunday, May 3, 2020 10:51 -0400 Hector Santos
<hsantos=[e-mail]> wrote:

> Is this a valid address?
> 
> 08:04:33.934 C: MAIL
> FROM:<github.agent:.github-hookshot/[e-mail]>
> 08:04:34.712 S: 250 2.1.0 Ok
> 
> with the ':' and also '/' ??

Technically, no.  The "/" is not a problem.  Colons are (they
are not in the list of valid characters for <atext> in RFC
5322), I imagine at least in part because they were part of the
now-discouraged Source Route syntax (see Sections 3.6 and
Appendix C of RFC 5321 (and 5321bis, at least so far)) and so
would need to be quoted.

You also need to be very careful with the "." following the
colon.  I haven't looked carefully enough at the syntax today to
have any confidence how that would be handled with the
Dot-string production -- you might have to quote the whole
business to make it valid.

I also note that, while the example you have given is well under
the 64 octets specified in RFC 5321 Section 4.5.3.1.1, I would
not be surprised if some addresses constructed that way would
push that limit and that there has been a recent discussion
about those limits.

> It appears to be accepted by various servers, including my own.

Yeah, no surprise.  I would be equally unsurprised if some
servers followed the spec and generated a syntax error because
of the colon.  There is also a very long history of various
systems messing up local-parts that use quoting as the quoted
strings pass through assorted processing steps.  And I'd also be
unsurprised if some servers are rejecting or messing up
local-parts much shorter than the specified maximum.


> This is related to a new project of handling a GitHub Webhook
> HTTP notifications sent to my web server.  The handler will
> the payload as a local message using the address:
> 
> From: github agent: github-hookshot/7431eee
> 
> That comes from an operator defined macro:
> 
> From: github agent: {GITHUB-AGENT}
> 
> Which is read from the JSON payload.
> 
> If the setup happens to send the notification to an email
> address, then the mail is exported for SMTP to sent out.

Noting that you seem to be turning blanks into ".", I'd also
want to be careful to be sure that any value "." characters to
the right of the "/" in your example don't get broken by any
de-conversion process. 

Also note that, if this is going to be used in conjunction with
web facilities, someone is likely to want to turn whatever you
produce into a MAILTO: URL and restrictions on those (both
restrictions imposed by the spec and those imposed by sloppy
implementations) are even worse.

> So I need to know if the address is valid. Its hard to
> decipher whether it is or not from the RFC5322/RFC5321 BNF. It
> seems to read the ':' and '/' characters are valid.

See above.  However, even if you quote the stuff using either
<qtextSMTP> or  <quoted-pairSMTP>, I predict that some servers
either won't accept it or will thoroughly botch it.  I'd also
predict that, when you complain, at least some of them will tell
you that no one has needed this in 37 years (or whenever their
mail system project started), that it would be a lot of work to
fix, and that you shouldn't expect it to work... or, in a few
cases, that they would be happy to accept a purchase order from
you or your customers to investigate a fix.  You could also
attempt to summon the Protocol Police, but I can assure you that
they are not accepting enforcement requests from this list.

Recommendation: Don't push it.  Remembering that only the
delivery server is permitted to interpret addresses and in spite
of the "%" routing syntax being out of favor these days, mapping 
   From: github agent: github-hookshot/7431eee

into something akin to

   MAIL FROM:<github-hookshot/[e-mail]>

is a great deal less likely to cause you, and your users, pain
and suffering in the long term.   And, of course, if you could
do it,

  MAIL FROM:<github-hookshot/[e-mail]>

would be even less likely to cause problems.

best,
   john