Prev: Error between two postfix "Command not recognized", RCPT iscut in two words
Next: client certificate?
From: Wietse Venema on 9 Jul 2010 20:22 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 |