Noel Jones wrote:
> Dennis // [EMAIL PROTECTED] wrote:
>> Hi all.
>>
>> I manage a few postfix spamfilter gateways for my company.
>>
>> They are doing a really god job of scanning mails and delivering them to
>> customers mailservers.
>>
>> The way we implement this is using a catch-all address to accept all
>> mail for customers domains, then scan the mail and try to deliver it to
>> the customers mailserver.
>>
>> This is of course a less than ideal solution, as i´m currently accepting
>> a lot of mails for remote-addresses that are non-existing. Which means a
>> few 100k mails scanned every day just to have the remote server bounce
>> it as the recipient does not exist.
>
> Right. If you send enough backscatter, you'll get blacklisted.
>
>>
>> I then thought of using the "reject_unverified_recipient" parameter,
>> thus letting the spamscanners probe the remote mailserver to see if the
>> recipient is valid or the mail would bounce.
>
> A fine solution if you are unable to get an actual list from the
> remote mailservers.
This is a not an option i´m afraid.
But how would recipient verification behave when the customers
mailserver is unavailable ?
Would one have to rely on the cache or would postfix hold the mail ?
>
>>
>> My questions are:
>> As the spamscanners are the best or primary MX´s
>> for the customers domains, would postfix then just probe itself, and
>> always get a positive answer due to my catch-all entry ?
>>
>> Or would postfix actually look at the transport map, and realize that it
>> has to probe the customers server. ?
>
> Postfix uses its normal routing methods with verification probes. If
> "normal" mail goes to the right place, verification probes will use
> the same channel.
>
>>
>> And how would one go about controlling the destination of the
>> probe-messages ?
>
> You probably don't need this, but here are the docs for probe routing:
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing
>
>
>
