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

[E Sam <[e-mail]>]

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.

On Fri, Jul 10, 2020 at 12:01 AM John C Klensin <[e-mail]> wrote:
>
> 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
>
>