Rob Maidment:
> On 23 June 2016 at 18:05, Wietse Venema <wie...@porcupine.org> wrote:
> > I don't see that happen.
> >
> > I don't think that postscreen is viable if it has to wait for DNS
> > lookup with EVERY SMTP CONNECTION.
>
> Ok I understand, but it wouldn't be on every connection, only the ones
> postscreen decided to pass through. And once a client IP is
> whitelisted the correct smtpd name for that IP could be retained in
> the cache.
Sorry, I cannot allow postscreen to become dependent on random DNS
servers. With DNS[BW]X servers one can expect that they respond
quickly; those DNS servers are determined by the local sysadmin,
not by some random client. With PTR lookups there is no expectation
about response times, the DNS servers are determined by the client,
and that would give a single bad actor too much control over
postscreen's performance.
If you need a system that distributes clients over different SMTP
service instances, then that can be done with a new daemon that
receives connections from postscreen, and that sends them to the
appropriate smtpd services.
> My problem is that I need the SMTP server to selectively offer SMTP
> AUTH (and STARTTLS) based on the domain name of the connecting client,
> as defined by the client IP's PTR record. I realise this has
> performance implications but that's the requirement I'm stuck with.
>
> Can I use smtpd_discard_ehlo_keyword_address_maps with a lookup table
> type of "socketmap" or "tcp" to connect to a custom lookup table
> server that would do the reverse look-up before responding?
That is possible. Socketmap is a bit more robust.
> I need to ensure TLS is used (and client certificates are verified)
> for some clients but not offered to others. What happens if I use
> smtpd_discard_ehlo_keyword_address_maps to strip the STARTTLS keyword
> but smtpd_tls_security_level is set to encrypt? Is the TLS
> enforcement code aware that TLS was not offered?
The SMTP session is in plaintext, and email delivery will fail.
Wietse
