From: Wietse Venema on
Sabahattin Gucukoglu:
> Hi,
>
> I am thinking about trying to replicate a feature I custom-built for my Se
>-ndmail installation, in Postfix. What this does is, whenever a host I am ba
>-ckup for is mentioned in the SMTP RCPT command, I check to see if the host i
>-s up, and *refuse* the command (450) if it is. The consequence of that is t
>-hat spammers, who normally buzz off when told, can be tested by a primary ho
>-st using all of the techniques at the primary's disposal - DNSBL, greylist,
>-etc. Any SMTP-time refusal is done by the primary, where it makes the most
>-sense, even after the DATA command where verification has no arbitration. F
>-inally, dictionary attacks have less effect since the probe is limited to st
>-arting up a connection and reading a banner once for the duration of the cac
>-he time.
>
> Unfortunately, this doesn't seem to be within the realm of Postfix's recip
>-ient address verification. Have I missed anything?

The purpose of sender or recipient verification is to reject bogus
addresses. To increase the realism of these tests, Postfix uses
the same mechanisms as regular mail i.e. it doesn't care if the
reply comes from a primary MX host or from a backup.

Moreover, Postfix assumes that a "positive" reply (the recipient
is "valid") can be cached for a significant amount of time.

You are trying to determine if the preferred MX host is up. I see
zero opportunity for code reuse here.

> Even if I were to set t
>-he temporary fail during verification code to 250, I'd potentially accept re
>-sponsibility for mail I shouldn't regardless of whether the host was really
>-up, if I could not queue verify probes. How can I get the desired effect, o
>-r will I need a policy server to do this?

Yes. There is nothing wrong with using one of the Postfix extension
interfaces to add a feature that isn't built-in.

Wietse