--On Friday, May 11, 2018 13:13 -0500 Spencer Dawkins at IETF
<spencerdawkins.ietf@xxxxxxxxx> wrote:
> Perhaps I've spent too much time talking to QUIC WG
> participants about header invariants, but can you actually
> change the encoding, or did you mean just adding a new
> encoding, so that if someone tries to respond to an earlier
> e-mail from someone with a re-written =40 address, that would
> still work?
Spencer, because I started the subthread, let me give you a
partial answer. I think you know this already, but probably
have other things on your mind. There is basically a firm rule
in SMTP (5321, but going back to 821 and maybe earlier) that
nothing in the mail path between what we now call the submission
server and the final delivery server gets to interpret, much
less tamper with, the internals of the local part of an address.
While we have many examples of systems breaking that rule, the
integrity of the mail systems depends on it in important ways.
Having a mailing list management system transform an address
between receipt and [re]distribution does not violate that rule
because we treat the message as having been delivered to that
system and then rewritten and hence not altered in that path.
However, had Alexey been writing very precisely, I don't think
he would have used "encoding" but instead talked about this as a
convention or something similar. Then the question becomes
whether, if the mailing list system changes an address using
that convention, whether the user, MUA, or delivery MTA at the
receiving end recognizes the convention.
Speaking as a user who sees that convention, it took me around
five seconds to figure out what =40 referred to (and it should
not have taken me that long). I don't know whether that would
be true of the typical IETF participant; it certainly is not
true of my delivery MTA or my now-ancient MUA.
So, there are really several possible questions:
(1) If your question is whether a recipient of the mailing list
distribution of the address would recognize the convention and
be able to infer the original address, the answer is "anyone's
guess", but most users tend to pay more attention to the
personal name phrase than to the address anyway, so maybe it
isn't important.
(2) If someone receives a message whose envelope MAIL FROM and
header "From:" fields show
"alexey=40example.com@xxxxxxxxxxxxxx"
and replies to it offlist without recognizing the convention or
de-converting the address, I assume that dmarc.ietf.org will
recognize its own convention, rewrite the message headers, and
send it off to alexey@xxxxxxxxxxx. If it does not do that
rewrite, then the message (or the copy addressed to him) bounces
or gets lost, which is not necessarily a bad thing. If it does
do the rewrite, it works even if the convention is changed to
"alexey☺example.com@xxxxxxxxxxxxxx"
as long as dmarc.ietf.org keeps track of all of the conventions
it has used. It does raise a privacy concern that might or
might not be important -- if I pick up Alexey's address (that
one) for use in a private reply, having the message pass through
IETF mail servers leaves traces (and possibly the message in
clear-text form and that might not be desirable.
(3) If the expectation is that a delivery server or receiving
MUA, upon receiving a message from, e.g.,
"alexey=40example.com@xxxxxxxxxxxxxx"
will recognize the convention, decode it and present
"alexey@xxxxxxxxxxx" to the user, well, don't hold your breath
waiting for it to happen with this convention so worrying about
how disruptive a change in convention might be is hardly worth
the effort. In addition, if we wanted / expected that
recognition to occur, I'd expect to see an Internet-Draft
proposing some sort of standards action to establish the
convention and encourage all mail systems to recognize it.
Alexey quite noticeably did not propose that.
best,
john
