Arnt Gulbrandsen:
> >>> 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.
> > ...
> >> Outgoing mail from that company to unicode addresses may begin to work,
> >> depending on whether the internal origin server supports EAI.
> >
> > Incorrect. This does not require any EAI support in the SMTP client.
> > The SMTP client simply hands the mail to the gateway without any
> > transformation of the recipient domain.
>
> If the best MX for the unicode recipient obeys RFC6531 section 3.4, then
> the SMTP client on the gateway has to use the SMTPUTF8 MAIL FROM parameter,
> ie. support EAI. By extension the origin server has to do the same.
You are missing the point. The internal SMTP client does not
look up the recipient MX host. It just gives the mail to the
perimeter gateway.
Therefore, a non-EAI internal SMTP client can send an email reply
to an EAI sender.
> > Is there a possibity that the same domain name may exist as an UTF8
> > string in some contexts and as xn-mumble elsewhere? If this is a
> > problem then it will affect many database lookups.
>
> As far as I can tell the xn-- mumble is never used outside the DNS lookups,
> neither in the RFCs nor in practice. The EAI RFCs say to use the xn-- form
> for MX lookups, to use an ASCII domain name for the EHLO argument, and
> otherwise don't discuss xn--.
Thus an EAI domain name may show up as xn--mumble in HELO commands.
> > First, all Postfix table lookups are case-insensitive by default.
> > You may have missed that.
>
> Indeed I did. Mydestinations will need more work, at least. I'll look at
> it.
>
> > Second, not all lookup tables may support UTF8. What does the POSIX
> > standard have to say about this for regular expressions? This
> > affects the regexp: table.
> >
> > Third, in database queries, strings that contain UTF8 may require
> > special treatment when the default locale is not unicode-based.
> > We must maintain compatibility with existing practice: Postfix
> > currently passes 8bit strings as if they are in the default locale.
> > It would be an unacceptable compatibility break if Postfix suddenly
> > starts to fail those queries just because they aren't well-formed
> > UTF8.
>
> Are you saying that at present, Postfix treats other people's 8bit as
> though it were case-insensitive in the server's locale? And that Postfix
> requires tables to be case-insensitive and silently expecting them to use
> the right locale?
I make seveal statements, and they are to be read separately. All table
lookups are case-insensitive by default. Apart from that, Postfix treats
8bit strings as in the current locale.
> > Finally, you appear to have broken the valid_hostname(3) abstraction.
> > This module enforces RFC rules for hostnames (and domain names) in
> > calls of infrastructure functions such as getaddrinfo(), getnameinfo()
> > and functions at lower levels in the stack.
> >
> > Unless the EAI RFCs say otherwise, the hostname in HELO commands
> > cannot be an UTF8 string, therefore it cannot be treated as if it
> > is a recipient domain.
>
> I agree (and I think I said as much in the README). That's why I call
> valid_hostname() in many cases and valid_mail_domain() in others.
It uses valid_mail_domain() in reject_invalid_hostname and
reject_non_fqdn_hostname, but in reject_unknown_hostname() it passes
the UTF8 string to dns_lookup_l().
> You've already found at least two holes, perhaps four. You told me earlier
> I needn't bother about minor improvements. Are these big enough that you'd
> prefer me to submit a new patch?
There will be more. I'll just document them and fix them, so I
don't have to spend a lot of time reviewing another version.
Wietse
