[EAI] HDR=UTF8SMTP (Re: draft-hurtta-eai-messagestore-00.txt)

[Frank Ellermann <nobody at xyzzy.claranet.de>]

Kari Hurtta wrote:

> You was taking it out from context.

Yes, but I read it top down once, and then used any cheap
shots I could find.  I like your ASCII art figures, they
make it much easier to understand what the prose is about.

> If HDR=UTF8SMTP parameter is added protocol, then there
> is also following possibility on table:

> - MTA rejects RCPT TO command which was local if
>   HDR=UTF8SMTP parameter was given on MAIL FROm -command.

How about joining BODY=8BITMIME with HDR=UTF8SMTP ?  What
I've in mind is this:

After the client said EHLO, indicating that it's willing
to hear which SMTP extensions are supported by the server,
the server may say that it can do UTF8SMTP plus 8BITMIME.

If the client wants 8BITMIME it will say BODY=8BITMIME.
In theory it can also say BODY=7BIT (I'm not sure how
that could be interesting for the server).

For what you have as HDR=UTF8SMTP a client would always
use BODY=8BITMIME.  This includes cases where the DATA
doesn't contain a single non-ASCII, but the MAIL FROM
(ending up as Return-Path) or a RCTP TO (ending up as
a from-clause or some X-EnvelopeSender header field at
least in theory) is an address with <UTF8-non-ASCII>.

That's quite a lot of parameters, ALT-ADDRESS, HDR, and
BODY.  If we're sure that HDR=UTF8SMTP _always_ implies
BODY=8BITMIME we can define a new BODY=UTF8SMTP joining
these parameters.

IFF.  Of course the name of the parameter is somewhat
misleading when it's used to talk about the header, but
the definition in RFC 1652 apparently fits.

IFF.  Otherwise we'd get a mouthful BODY=8BITMIME plus
HDR=UTF8SMTP plus (optional) ALT-ADRESS=foo at bar.example
plus (likely) raw UTF-8 in the MAIL FROM address, which
would render the two BODY + HDR parameters as redundant.

After all the client is talking to a server claiming to
support UTF8SMTP + 8BITMIME.

> it is often late in also when final MTA rejects message
> on SMTP level.  Usually picture is:
[trimmed by me]
|            +-------------+             +-------------+
|            |  "border"   |             |    final    |
| --ESMTP--> |    MTA      |  --ESMTP--> |     MTA     |
|            +-------------+             +-------------+

Yeah, a picture I've used on the SMTP list where those
"ADMDs" in the email-arch I-D try to hide the existence
of this border behind fog was this:

          +-----+   +-----+ : +-----+   +-----+
         /| MSA |-->| MO  |-->| MX  |-->| MDA |\
        / +-----+   +-----+ : +-----+   +-----+ \
+-----+/     |       ^ ^    :    |       ^ ^     \+-----+
| MUA |      | +-----+ |    :    | +-----+ |      | MUA |
+-----+\     V V       |    :    V V       |     /+-----+
        \ +-----+   +-----+ : +-----+   +-----+ /
         \| MDA |<--| MX  |<--| MO  |<--| MSA |/
          +-----+   +-----+ : +-----+   +-----+

For a mail flow mainly from left to right the left half
is an "MON" (mail originiating network, without counting
"ADMDs"), and the right half is an "MRN" (mail receiving
network) in Keith's terminology.

That picture is too simple to cover mediators, or details
of various MXs.  But it covers the important point that
the border MTA (MX) and the final delivery MTA (MDA) are
different.

In your I-D you've made it more interesting by adding an
LMTP hop between MDA and final delivery MTA.  One or two
hops isn't that important for "reject" vs. "bounce", at
least one is enough to get into serious trouble - either
forced to drop mails, or to send bounces to unverified
addresses.

> Anything what was rejected by final MTA tend to cause
> backscatter on case of junk mail with forged return path.
> Often that is full mailbox.  That information is quite
> difficult to transfer to "border" MTA.

So far all my attempts to convince the Spamcop folks that
this case can legitimately happen (for SPF NONE or NEUTRAL)
failed miserably.

But the info "legacy mailbox" vs. "EAI mailbox" isn't as
volatile as "mailbox full" (or not), it's more like the
info "mailbox exists" (or not).  We're talking about a
single bit, I don't care how it's tranferred to the MX.

And for an SPF PASS I don't care if it's transferred at
all, actually "PASS" stands for "legit bounces welcome".

Frank



_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima