Andreas Weigel:
> Hi,
>
> I recently noticed some (for me) unexpected behavior with address
> verification probes (reject_unverified_recipient in
> smtpd_relay_restrictions). Given an envelope recipient with a local part
> in Quoted-String format
> (https://datatracker.ietf.org/doc/html/rfc5321#page-41) that contains a
> colon, the verify daemon unconditionally replaces that colon by an
> underscore; e.g., specifying the following recipient during the SMTP
> conversation
>
> RCPT TO: <"a:b"@example.org>
>
> causes the verify daemon to initiate the sending of a probe to
> <a...@example.org>. Using postfix's verbose debug output I verified that
> the smtpd passes the address as a:b...@example.org to the verify daemon,
> which then changes that.
>
> In postfix/src/verify/verify.c --> static void verify_query_service(...)
> I find
>
> translit(STR(addr), ":", "_");
>
> which I would deem the code responsible for the observed behavior.
>
> I'd expect the verify daemon to re-quote the local part when sending out
> a probe in that case, i.e. transmit a probe for <"a:b"@example.org>. Am
> I overlooking some obvious issue here why this would be a bad idea?
This code was added 17 years ago, with a comment that it was neutering
(making harmless) the ':' in IPv6 address literals, but I do not
immediately recall
- what the problem was with localpart@[ipv6:address].
- why this simple substitution was considered adequate.
The email address is used as a cache storage/lookup key, and for
sending a probe request. The cache does not care if there is ':'
in a storage or lookup key. Still, if the problem was with the
cache, then the 'fix' could have neutered the ':' only for the cache
lookup key without changing the address used in a probe.
If it was a concern about the handling of probes, then perhaps that
was because a sender address it not validated as strongly as a
recipent address. A recipient address must resolve to an authorized
domain, and Postfix is paranoid about sender-specified routing to
circumvent policies. Such restrictions are rarely applied to a
sender address. And of course sender address verification was a big
use case of the verify daemon.
I'll have to think about this a bit more.
I also wonder if after 17 years this should get attention all.
Wietse
