Hi,
thank you for the quick response and explanation.
> I also wonder if after 17 years this should get attention all.
I do understand that it is probably not really critical. I noticed the
behavior with a non-standard case of having that colon as a delimiter
within artificially constructed mailbox addresses and was able to work
around by just choosing a different one.
AFAICS it does break recipient (or sender) address verification for any
mailbox containing a ":", though. How many of those are practically
encountered in the wild I cannot say, but probably not too many given
that this has been in the code base for so long :)
Andreas
On 13.06.22 17:48, Wietse Venema wrote:
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
