Subject: [ietf-smtp] enhanced reply codes for BINARYMIME?

From: John Bucy <[email-masked]>
Date: Fri, 15 May 2015 11:32:35 -0700

On the subject of smtp enhanced status codes, am I correct in understanding
there is not currently a code for "mailbox does not accept binary messages"
a la 5.6.7 for SMTPUTF8?

thanks
john

---

From: "John Levine" <[email-masked]>
Date: 16 May 2015 17:05:29 -0000

>there is not currently a code for "mailbox does not accept binary messages"

At the time, I think the thought was that the sender would recode the
MIME parts as something less binary, base64 or qp, and try again.

Ned Freed's address is used as an example in the RFC so he may well
have more concrete observations.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sat, 16 May 2015 10:26:53 -0700 (PDT)

> there is not currently a code for "mailbox does not accept binary messages"

Not as far as I know. That said, while I understand that a mailbox matter is,
properly speaking, something that calls for a x.2.y code, it's not that much of
a stretch to have a mailbox issue manifest as a media incompatibility instead.

In other words, I don't see why you just don't use 5.6.7 and be done with it.

				Ned

---

From: John Bucy <[email-masked]>
Date: Mon, 18 May 2015 13:06:59 -0700

Ah, I didn't look hard enough! In 3463, there's

      X.6.3   Conversion required but not supported

         The message content must be converted in order to be forwarded
         but such conversion is not possible or is not practical by a
         host in the forwarding path.  This condition may result when an
         ESMTP gateway supports 8bit transport but is not able to
         downgrade the message to 7 bit as required for the next hop.

which seems about right.

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 May 2015 14:02:42 -0700 (PDT)

> which seems about right.

For not being able to deliver an SMTPUTF8 message to a particular mailbox?
If so, I don't that code is especialy appropriate. The entire design of
the current EAI specification is based on there not being any conversions
other than in the limited case of displaying a delivered message to a
client that doesn't support the extension. 

Given that's the design, how does it make sense to claim that a required
conversion is missing when no such conversion is defined or even possible?

And even if that weren't the case, I think things are likely to work better if
you use a code that's specific to SMTPUTF8 rather than a generic one. To the
extent anyone looks at these things, they're not likely to interpret 5.6.3 as a
SMTPUTF8 failure.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 18 May 2015 21:35:07 -0000

>For not being able to deliver an SMTPUTF8 message to a particular mailbox?

Nope, this is for not being able to deliver BINARYMIME.  Amazingly, the subject
line in this thread still matches the topic.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 May 2015 22:38:12 -0700 (PDT)

> line in this thread still matches the topic.

My bad. Yes, I'd say that 5.6.3 is the appropriate code for that, since
a conversion is definitely possible.

				Ned