Subject: [ietf-smtp] Fwd: [dispatch] Forced SMTP redirects

From: E Sam <[email-masked]>
Date: Thu, 9 Jul 2020 22:47:48 -0400

Hello all,
See the below email chain - I thought it would be a good idea to send
this to the ietf-smtp mailing list as well.

Thanks

---------- Forwarded message ---------
From: John Levine <[email-masked]>
Date: Thu, Jul 9, 2020 at 9:59 PM
Subject: Re: [dispatch] Forced SMTP redirects
To: <[email-masked]>
Cc: <[email-masked]>

I'd suggest reposting this to the ietf-smtp list where people who've
been around a lot longer than I have can explain why nobody implements
551 redirects (and as far as I can tell, nobody ever did) and there is
assigning a different response code won't change that. It may seem
like a good idea, but turns out not to work in practice.

FWIW I looked through the last seven months of my mail server's logs
and the total number of 551 responses is zero.

R's,
John

PS: There have been some attempts at setting up change-of-address
services where you can register old and new addresses, so mail servers
could query them after getting a 550, and they never went anywhere either.

See US Patents 6,654,789, 6,892,222, and 7,080,122.

On the other hand, a lot of mail systems now let users keep their
addresses after they leave, ranging from ISPs like Comcast and
Spectrum to universities who turn student addresses into alumni
addresses. They let you forward the mail, or you can add it to
the list of accounts your MUA checks, or either or both.

In article <[email-masked]>
you write:
>Hello everyone,
>
>
>I have published a new internet-draft that might be of interest.
>
>
>As always, its on the Datatracker:
>
>https://datatracker.ietf.org/doc/draft-sam-smtp-redirects/

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jul 2020 00:01:00 -0400

Hi.

Well, I largely agree with John Levine except for a bit of
history that just proves his point.   Many years ago, at sort of
the dawn of SMTP and at least in the environments I was working
in, the use of 251 and 551 was fairly common, as was the use or
VRFY to check out addresses.  Over the years, all three fell
into disuse as John says.  Especially for the former two, that
happened at least as much due to concerns about a variety of
attacks as about information disclosure.  Section 7.5 for RFC
5321 at least hints at the problem: if, as an SMTP-sender, I get
a 557 or 558 (or a 551), I'd better be really sure that the
system returning that code is authoritative for the addresses in
question.  That gets especially complicated when there is a
multihop relay chain and, especially if the practice of opening
the outgoing connection before the incoming one has completed,
one cannot tell with any certainty where the report came from.

Also remember that SMTP encourages, nay requires, that if an
SMTP-sender gets back a reply code it does not recognize, it is
required to ignore anything but the first digit.  That predicts
a fairly hard road at this point for new codes that are intended
to convey subtle information.

Agreeing with John that the underlying problems are not ones
that new codes will solve and hence that the likelihood of
acceptance and wide enough deployment to make this useful are
low, two suggestions:

(1) Stick with 551 but add extended codes that reflect exactly
what you want and the distinctions you are trying to make.
There may still be little adoption, but I believe (after not
much thought) that the chances of harm are lower.

(2) Expand your Security Considerations section (or some other
section) to consider a broader range of possible attacks and
configurations.  For example, if encryption is only hop-by-hop,
any server that has been compromised seriously enough to tell a
client to rewrote a message probably has access to the plaintext
in any sort of pipelining situation and likely some others.  An
analysis of what happens if the server generates these codes and
the client interprets them as simply 5yz (as suggested above)
and whether that would cause harm would be in order.  Similarly,
suppose

   SubmissionServer -> MTA1 -> MTA2 -> DeliveryMTA

Now, let's assume MTA2 is an enterprise server with a list of
forwarding addresses delivering only virus-checked messages with
valid addresses to DeliveryMTA  (a plausible situation in
today's world).  So it generates a 557 code.  As I read your
draft (perhaps too quickly) you expect MTA1 to forward/resend
the message to the [new] correct address.  But, if it does, what
is it going to tell the submission server (if anything)
especially if it, having received the message and agreed to pass
it on, has already returned a 250 code and gotten QUIT in
return.   That takes us into NDN/DSN territory with all of the
issues associated with those messages, in this case probably
with a need to authenticate them end-to-end.

best,
   john

--On Thursday, July 9, 2020 22:47 -0400 E Sam
<[email-masked]> wrote:

> Hello all,
> See the below email chain - I thought it would be a good idea
> to send this to the ietf-smtp mailing list as well.
> 
> Thanks
> 
> I'd suggest reposting this to the ietf-smtp list where people
> who've been around a lot longer than I have can explain why
> nobody implements 551 redirects (and as far as I can tell,
> nobody ever did) and there is assigning a different response
> code won't change that. It may seem like a good idea, but
> turns out not to work in practice.
> 
> FWIW I looked through the last seven months of my mail
> server's logs and the total number of 551 responses is zero.
> 
> R's,
> John
> 
> PS: There have been some attempts at setting up
> change-of-address services where you can register old and new
> addresses, so mail servers could query them after getting a
> 550, and they never went anywhere either.
> 
> On the other hand, a lot of mail systems now let users keep
> their addresses after they leave, ranging from ISPs like
> Comcast and Spectrum to universities who turn student
> addresses into alumni addresses. They let you forward the
> mail, or you can add it to the list of accounts your MUA
> checks, or either or both.
> 
> 
> 
> 
> In article
> <[email-masked]
> l.com> you write:
>> Hello everyone,
>> 
>> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: "John Levine" <[email-masked]>
Date: 10 Jul 2020 00:30:53 -0400

>See US Patents 6,654,789, 6,892,222, and 7,080,122.

By the way, 6,654,789 expires a week from Monday and 6,892,222 expired
last year so if you find any good ideas in them, you can use them.

7,080,122 doesn't expire until 2023.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jul 2020 01:23:52 -0400

And then, of course,  there were the bright ideas about
universal/ global email directories.  One hesitates to describe
where those went  :-(

   john

--On Friday, July 10, 2020 00:30 -0400 John Levine
<[email-masked]> wrote:

> In article
> <CAKFo7w=[email-masked]
> l.com> you write:
> By the way, 6,654,789 expires a week from Monday and 6,892,222
> expired last year so if you find any good ideas in them, you
> can use them.
>

---

From: E Sam <[email-masked]>
Date: Fri, 10 Jul 2020 07:57:09 -0400

I see, well use of the code/codes wouldn't be required so multihop
relays could refuse to use it. The purpose behind it is mainly people
that want to be able to change their email addresses. As for which
would be the server of "truth", it would be the MX server (in the MX
record) of the original email address. A user would configure their
server to use these new response codes to change their email.

If MTA1 decides to forward instead of 551, then it wouldn;t be needed
to provide the email address behind the multi relay.

In a corporate environment, it would make sense not to use these
codes, but with personal emails, it would make more sense in my
opinion.

If there is an email address belonging to DeliveryMTA, then MTA1
shouldn't use the 551 code. But if there is a email address that is
"hard linked" to another SMTP server (lets say another chain of MTAs
with the MX record pointing at the first link), then usage of the
codes is recommended.

I'll respond to more of your email later as I want to take a deep look
in the issue again.

---

From: "John R Levine" <[email-masked]>
Date: 10 Jul 2020 11:21:34 -0400

> universal/ global email directories.  One hesitates to describe

I have my copy of the 1994 Internet White Pages, edited by Seth Godin and 
James McBride, right here if there's anything you need to look up.  The 
first half is sorted by person's name, the second half by domain name.

You're [email-masked].  It has five addresses for me, two of 
which still work and a third which I could turn back on if I wanted to.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 10 Jul 2020 22:32:45 -0400

In article <[email-masked]> you write:
>that want to be able to change their email addresses. 

I'm pretty sure we all understand what you're proposing. This is not a
new idea -- it is the same thing the 551 code did in RFC 788 in 1981.

Given that 551 has been a failure for four decades, and that long term
forwarding is widely used to address the same problem, you need to
explain why this proposal is different, and who you think is likely to
implement it.

Keep in mind the point about multihop relays. For anyone who uses a
mail program like Outlook or Thunderbird, this won't work, and that's
a lot of people. We try to define standards in ways that work for
everyone.

It would also be a good idea to show that you're familiar with other
attempts to solve this problem and why they have or (mostly) haven't
worked. You could start with the three patents I cited.

R's,
John