Russell Yanofsky:
> Thanks for taking a look at the patch. I attached an updated version
> that uses vstring primitives and adds the missing free.
>
> On Thu, Jun 16, 2016 at 7:42 PM, Wietse Venema <wie...@porcupine.org> wrote:
> > One complication is that the smtpd_resolve_addr cache is not only
> > used for validating recipients, but also for validating senders.
> > See check_sender_rcpt_maps(), which is used by reject_unlisted_sender
> > and smtpd_reject_unlisted_sender.
> >
> > It don't know if your patch also makes that case work better, but
> > I suppose it is sufficient if it does not make things worse.
>
> I guess in the context of reject_unlisted_sender, there are two cases
> where behavior would change.
>
> Case 1: When postfix is configured to allow mail from the sender
> address to itself, but not allow mail from an arbitrary address to the
> sender. In this case, sender address will now be considered listed
> instead of unlisted.
>
> Case 2: When postfix is configured to not allow mail from the sender
> address to itself, but to allow mail from an arbitrary address to the
> sender. In this case, the sender address will now be considered
> unlisted instead of listed.
I have opted to use the recipient as the "sender context" for sender
address resolving, if the recipient is available. This means that
the sender will "exist" when the recipient is allowed to send mail
to it.
> Both cases seem like they should be pretty rare. For case 1, the
> change seems to me like it would be an improvement. For case 2, the
> configuration seems nonsensical to begin with so I think it would be
> harmless.
>
> > Always indexing the "resolve address" cache by sender+recipient
> > makes the cache less effective for everyone, and I expect that
> > almost no-one uses sender-dependent routing. So I may prefer to
> > make that part dependent on whether sender-dependent routing is
> > actually enabled.
This is to avoid resolving the same email address every time you
use reject_unlisted_xxx, reject_unknown_xxx_domain, check_xxx_access,
check_xxx_mx_access, and a bunch of other things in the same SMTP
session.
After that post I have implemented a fix that covers all the usess
of smtpd_resolve_addr(), including Milters that want to know what
"transport" or "nexthop" an email address resolves to.
It is part of postfix-3.2-20160619.tar.gz
Wietse
