[Top] [All Lists]

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

2020-07-10 06:57:35
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

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.

On Fri, Jul 10, 2020 at 12:01 AM John C Klensin <john-ietf(_at_)jck(_dot_)com> 


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,

   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.


--On Thursday, July 9, 2020 22:47 -0400 E Sam
<winshell64(_at_)gmail(_dot_)com> 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.


---------- Forwarded message ---------
From: John Levine <johnl(_at_)taugh(_dot_)com>
Date: Thu, Jul 9, 2020 at 9:59 PM
Subject: Re: [dispatch] Forced SMTP redirects
To: <dispatch(_at_)ietf(_dot_)org>
Cc: <winshell64(_at_)gmail(_dot_)com>

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.


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
<CAKFo7wkawgk-Yj676kE5MqK8XuebuArMexH-eOdq_Uo7ijdimQ(_at_)mail(_dot_)gmai> you write:
Hello everyone,

I have published a new internet-draft that might be of

As always, its on the Datatracker:

ietf-smtp mailing list

ietf-smtp mailing list