Subject: [ietf-smtp] SMTP status codes 251 and 551

From: "John R Levine" <[email-masked]>
Date: 9 Feb 2020 21:58:05 -0500

SMTP has had the 251 and 551 status codes for a long time, since RFC 788 
in 1981.  The 251 code means (roughly) I'll accept this address but I'll 
forward it to <x>, and 551 means address rejected, send it to <x> instead. 
The idea is that the sending system should note the <x> address so in 
future it sends mail directly there.

Did anyone every actually implement these, and in particular the sender 
side to remember and redirect?  You don't have to tell me all the reasons 
it's a bad idea, many of which are described in the RFCs.  I'm just 
wondering whether this was ever real, or it just seemed like a good idea.

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Feb 2020 12:02:29 -0500

--On Sunday, February 9, 2020 21:58 -0500 John R Levine
<[email-masked]> wrote:

> SMTP has had the 251 and 551 status codes for a long time,
> since RFC 788 in 1981.  The 251 code means (roughly) I'll
> accept this address but I'll forward it to <x>, and 551 means
> address rejected, send it to <x> instead. The idea is that the
> sending system should note the <x> address so in future it
> sends mail directly there.
> 
> Did anyone every actually implement these, and in particular
> the sender side to remember and redirect?  You don't have to
> tell me all the reasons it's a bad idea, many of which are
> described in the RFCs.  I'm just wondering whether this was
> ever real, or it just seemed like a good idea.

John,

If you ask me about how many implementations that are currently
active and in heavy use, I don't know, but 251 and 551 were part
of the same thinking that produced the VRFY (and, to a lesser
extent, EXPN) commands and were very widely implemented and
used, even more so as many institutions, especially academic
ones, shifted from [email-masked]
addressing to preferring [email-masked] addressing.  They
were especially important when  some institutions were willing
to forward or otherwise handle messages for a while to the new
jobs/ institutions of faculty and staff who had left but did not
want to have to do that indefinitely and hence wanted to notify
senders to update their address books.  IIR, there were even a
few MUAs around that would pick the information up and turn it
into a "do you want to update the address in your address book?"
questions to the users.

My very vague recollection is that even at least one of the
second-generation BITNET-Internet mail gateways supported 551
functionality.  

Now, in today's far more hostile world, there are, as you
suggest, many reasons why they, perhaps especially 251, are bad
ideas on the public Internet.  I would guess that
implementations that still support those codes and the
associated actions have configuration options to turn them off,
either globally or for mail send outside the organization or
enterprise and that "off" is the preferred default.  I can
actually see some advantages for organizations that divide up
their internal mail systems by laboratory or country (and
pressure to do the latter from privacy law differences) when
people make intra-company moves.   But, no, one cannot get rid
of them on the basis of "never implemented or deployed".

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2020 15:10:55 -0500

In article <644DAD60BFC9A9FC2C84194A@PSB> you write:
>...  I can actually see some advantages for organizations that divide up

That's not what I was planning, although it might be interesting to
try returning some 251 codes and see how well it works.

For an article I'm writing, I'm figuring out what to say about the
slow demise of mail forwarding.

My recollection of the 1980s is that you normally had one e-mail
address.  If you moved, you'd get a new address, perhaps with a
temporary courtesy forward like for paper mail.  There were
distribution lists, but they felt different from normal addresses.  I
don't get the impression there were a lot of role addresses other than
postmaster.

Now there are role addresses, "permanent" forwarding addresses, and
many ISPs let you keep your address even if you stop being a customer
(Comcast and Spectrum in the U.S.)  You'd like them all to forward
mail to the one place you read it, but increasingly it doesn't work.

One issue is naive spam filtering.  Any time a system does forwarding
at scale, some of what's forwarded will be treated as spam because no
two spam filters work the same.  Sensible filters don't block known
forwarders unless something really bad happens.  I hear that a poorly
supervised robot at Proofpoint is currently blocking forwarded mail
from Tucows' large hosted mail system, which in effect makes the mail
disappear.  Dunno if Tucows sends DSNs but if they do a lot of the
senders aren't prepared to deal with them.

Another is DMARC.  I host the mail for my local town government.  Most
of the users read their mail at Gmail, and despite making no
modifications to mail other than adding ARC headers, Gmail rejects a
lot of it due to overstrict sender DMARC policies.  The usual issue is
that they do DMARC on the cheap using only SPF validation, no DKIM,
which of course can't deal with forwarding.

Another large change since the 1980s is that then most people read
their mail on the same computer where the mail was stored, now nobody
does and we all use IMAP.  So I've told the town people how to set up
Gmail to collect mail from a mailbox here and switched back to local
delivery.  That avoids nearly all of the delivery issues since there's
no DMARC checks on fetched mail and for the most part it assumes that
stuff being fetched is OK.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 10 Feb 2020 12:17:31 -0800

> stuff being fetched is OK.

Seems like an interesting security/spearphishing hole - find someone who
receives mail on a system that might not be as aggressively filtered and
then reads it via another service which might not apply the same rigor or
warnings for fetched mail as it would for delivered mail. Of course most
mobile MUAs fall squarely into that latter category besides which security
items are the first things to be elided from the UX due to screen pixel
shortages.

--Kurt

---

From: "John R. Levine" <[email-masked]>
Date: 10 Feb 2020 15:45:52 -0500

On Mon, 10 Feb 2020, Kurt Andersen (b) wrote:
>> delivery.

> warnings for fetched mail as it would for delivered mail.

I suppose that's hypothetically possible, but it seems like a lot of work 
to exploit a pretty obscuure loophole.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: George Schlossnagle <[email-masked]>
Date: Mon, 10 Feb 2020 15:41:04 -0500

> slow demise of mail forwarding.

We see a good bit of email here and the number of 551s that seem to
indicate forwarding is being suggested is incredibly tiny.  I could run
some stats if you like, but call it < 0.0002% over the past year's bounces.

Email being what it is, there's lots of use of 551 for other purposes
(anti-abuse feedback, etc).

George

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2020 21:45:58 -0500

In article <CAO=[email-masked]>,
>some stats if you like, but call it < 0.0002% over the past year's bounces.

Thanks.  Do you see any 251 at all?

>(anti-abuse feedback, etc).

Not surprising.  In response to RCPT TO or something else?

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 Feb 2020 10:52:25 +0100

> Thanks.  Do you see any 251 at all?

251's cannot be seen, except in the mail log.  While "551 send to <x>" is
manually actionable by the author who receives the bounce, 251 is not, unless
someone enables positive delivery notification.

FWIW, in my tiny log files I found a few improper replies like the following,
in the period September-December 2014:

    551 5.0.0 This message was classified as spam

and no 251 at all.

Using Courier-MTA, I'd have to devise a new add-on in order to issue these
responses using configured forward addresses.  Do Sendmail or Postfix provide
for email address portability?

Best
Ale
--

---

From: Sebastian Hagedorn <[email-masked]>
Date: Tue, 11 Feb 2020 11:24:29 +0100

> for email address portability?

I only found this reference in the release notes for sendmail 8.8.8:

        Drop recipient address from 251 and 551 SMTP responses per RFC 821.
                Problem noted by Kari E. Hurtta of the Finnish Meteorological
                Institute.

That doesn't sound like sendmail actually handles the forwarding.
-- 
    .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
   .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 11 Feb 2020 10:34:40 +0000

> for email address portability?

Exim does permit a config to specify the response code and message.
-- 
Cheers,
  Jeremy

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 11 Feb 2020 14:01:19 +0100

On Monday 10 February 2020 21:41:04 CET, George Schlossnagle wrote:
> We see a good bit of email here and the number of 551s that 
> seem to indicate forwarding is being suggested is incredibly 
> tiny.  I could run some stats if you like, but call it < 0.0002% 
> over the past year's bounces.

I'm morbidly curious... if it would be simple for you to find out, I'd love 
to see the banner lines were for the servers that support 551-forwarding.

Arnt

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Feb 2020 10:32:52 -0500

> On Feb 11, 2020, at 4:52 AM, Alessandro Vesely <[email-masked]> wrote:
> 

Postfix supports a "relocated_maps" feature, which aims to refer the
bounce recipient to a more appropriate address:

	http://www.postfix.org/postconf.5.html#relocated_maps

When a RCPT TO hits a listed address it looks like the response will be:

	550 5.1.6 User has moved to <lookup result>

The 5.1.6 is determined in the mailer triple resolution code, which is
is SMTP independent, and 3-digit SMTP reply code is determined in the
SMTP engine, which maps replies with 550 for all addresses that
resolve to the error channel.

   https://tools.ietf.org/html/rfc3463#section-3.2

        X.1.6   Destination mailbox has moved, No forwarding address

         The mailbox address provided was at one time valid, but mail is
         no longer being accepted for that address.  This code is only
         useful for permanent failures.

But the result is correct, Postfix is not returning a machine-readable
551 referral, it is returning a human readable[1] 550 reject.

-- 
	Viktor.

[1] By humans who can read and understand a short English phrase.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Feb 2020 18:42:54 +0100

> 	550 5.1.6 User has moved to <lookup result>

That would look like a perfect 551 candidate, wouldn't it?

>         X.1.6   Destination mailbox has moved, No forwarding address

I'm not familiar with extended status codes, but "No forwarding address" seems
to mean that there is no <lookup result>.  Curiously, looking in the IANA page:

https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml

One can find other uses of 251 and 551, not related to forwarding for address
correction.  OTOH, no extended status code provides for address correction.  Is
that the reason why Postfix relocated maps reply 550 rather than 551, perhaps?

> [1] By humans who can read and understand a short English phrase.

I'm sure most people on this list can read NDN.  However, generic users who
have no idea of the SMTP dialogue find them difficult to grasp, especially
backscatter.  Maybe we're not so human, after all...

Best
Ale
--