On Wednesday, June 4, 2014 12:55:18 PM CEST, Wietse Venema wrote:
I have looked at parts of the patch in my copious time.
I hoped someone else would ;) I do feel a little guilty about imposing on
you alone.
First, Postfix behavior must not change unless mail is flagged as
EAI, regardless of whether it contains 8-bit headers or envelopes.
Are you sure?
I quite agree about 8-bit use in most of the messages, but we now have an
RFC that lays exclusive claim to how to interpret 8-bit in localparts and
domains. Anyone who uses 8-bit localparts/addresses incompatibly will have
a bit of a problem in the future.
Thus, the SMTP client, cleanup daemon, and other daemon programs
MUST NOT engage into any EAI-related stuff unless a message is
flagged as EAI-enabled. I will add a guard around that code.
The smtputf8 flag in the queue file acts as such a guard. I noticed that
postfix tends to trust the queue, so I followed along with that: If the
queue file doesn't say smtputf8, then e.g. the SMTP client will happily
send 8-bit localparts.
The SMTP server is the biggest exception. It actually refuses 8-bit
localparts/domains unless the SMTPUTF8 flag is set. The RFC says it must.
If you'd rather not, just skip the two if() clauses in smtpd.c that mention
error code 5.6.7.
The other exceptions is in the DSN generation, where some error codes may
change, and in printable(), which now considers UTF8 to be printable for
formerly did not.
As for EAI auto-detection in Postfix the sendmail command, I will
make that configurable if it isn't already.
Very good point. Like this, perhaps:
diff --git a/src/sendmail/sendmail.c b/src/sendmail/sendmail.c
index f23dc9f..e3019bb 100644
--- a/src/sendmail/sendmail.c
+++ b/src/sendmail/sendmail.c
@@ -778,6 +778,7 @@ static void enqueue(const int flags, const char
*encoding,
}
}
+#if !defined(NO_EAI)
/*
* If either the sender or any recipients contain non-ascii
* characters, then this message has to be sent with the SMTPUTF8
@@ -788,6 +789,7 @@ static void enqueue(const int flags, const char
*encoding,
rec_fprintf(dst, REC_TYPE_ATTR, "%s=%d",
MAIL_ATTR_SMTPUTF8, 1);
}
+#endif
/*
* Append the message contents to the queue file. Write chunks of at
most
Have you given any thought of what happens when a company installs
Postfix-EAI on the perimeter, and wants to forward the mail to their
internal systems that may or may not have EAI support?
Yes.
Mail between that company and other ASCII addresses works as before, in
both directions.
Outgoing mail from that company to unicode addresses may begin to work,
depending on whether the internal origin server supports EAI.
Incoming mail to that company from unicode addresses still doesn't work.
Until now Postfix would accept 8-bit localparts but frown on 8-bit domains
in the MAIL FROM command. Now it will accept 8-bit domains too, but if the
internal systems don't, then the perimeter server will generate a DSN when
it tries to forwad the mail.
Postfix has already passed 8-bit headers and envelopes for 15 years
and we can't suddenly stop doing that when a down-stream system
doesn't announce SMTPUTF8.
In that case you'll want to remove the two smtpd.c blocks that mention
error code 5.6.7.
I haven't looked yet at the interface with database systems.
At this interface we can expect characterset issues.
I changed printable(), so e.g. any log systems that only accepted ASCII may
get problems. Things like recipient table lookups always had to accept
8-bit localparts, now they have to accept 8-bit domain side too.
Other issues should be unlikely, since the eightbittery is passed along
without any actual changes. No upcasing, downcasing, charset conversions or
other complications. The only conversion the code does is just before it
does an MX lookup.
Arnt
