[EAI] Re: HDR=UTF8SMTP
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EAI] Re: HDR=UTF8SMTP
Kari Hurtta wrote:
> BODY=BINARYMIME does not fit to picture.
Sorry, I only checked 1652 and forgot this.
> Therefore BODY=UTF8SMTP does not fly.
A pair of parameters like UTF88BITMIME and
UTF8BINARYMIME could cover it. With nicer
names, maybe.
Anyway, some parameter like HDR=UTF8SMTP is
required, otherwise MTAs would be forced to
receive DATA that they have to reject at the
end of DATA.
With that parameter they can reject a.s.a.p.
per receiver (for a legacy mailbox). We get
a new reply code "erroneous BODY parameter"
for a missing HDR=UTF8SMTP (after DATA).
An unnecessary HDR=UTF8SMTP is also ugly if
a wannabe message/utf-8 was rejected for a
legacy mailbox, and later turned out to be
no message/utf-8. But what went wrong in
this case should be obvious for the sender,
it's not the job of the server to outsmart
the client.
###
One day later after some sleep: My idea to
use HDR=UTF8SMTP based on the header and
info that _could_ be added by the server in
a timestamp line or Return-Path or some
non-standard "envelope to" header field was
*_horribly_* wrong.
HDR=UTF8SMTP has to reflect what really is
in the header, not what might end up there.
This gets us the interesting case, where a
mail arriving without HDR=UTF8SMTP has to be
forwarded with it. Depending on what the
MTA adds to the header (only ASCII or UTF-8).
###
I think HDR=UTF8SMTP is not some premature
optimization, it's required for all cases
where some mailboxes accept message/utf-8
and others don't.
Otherwise the mail is in essence sent (N+1)
times: 1st attempt, receivers 1...N, no
UTF-8 in the envelope, but in the header,
server says "5xx some users hate UTF-8"
afte DATA.
2nd attempt (receiver 1), etc. up to (N+1),
each with a single RCPT TO trying to find
out which of the N receivers accept UTF-8.
OTOH with HDR=UTF8SMTP the whole business
for N receivers can be handled at once.
Frank
_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.