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

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

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
<[e-mail]> 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
> 
> ---------- Forwarded message ---------
> From: John Levine <[e-mail]>
> Date: Thu, Jul 9, 2020 at 9:59 PM
> Subject: Re: [dispatch] Forced SMTP redirects
> To: <[e-mail]>
> Cc: <[e-mail]>
> 
> 
> 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
> <[e-mail]
> l.com> 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/
> 
> _______________________________________________
> ietf-smtp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp