Thanks for the info Len! Do you happen to know if there is a time-to-live associated with the cached records, or do you have to manually remove records from the database that are no longer valid (for example, an e-mail account that is no longer valid on the IMail server)?
Bill ----- Original Message ----- From: "Len Conrad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 07, 2003 2:20 PM Subject: [IMGate] Re: bug in Imail for peer >Len, is the reject_unverified_recipient a snapshot feature? yes, reject_unerified_(recipient|sender) are certainly in the snapshots, don't now about the release. SAV is certainly not in release, don't know about RAV > Are you saying >that you can configure Postfix to hold an inbound message while checking the >IMail server to see if the recipient address is valid or not before >accepting delivery of the message by implementing the >reject_unverified_recipient feature? yes. It's not as good as exporting the user list from Imail to ImGate, but it's much better than IMGate doing per-domain relaying. >So if IMail responds 550 user does not exist, Postfix will send a 550 user >does not exist to the sending mail server, and if IMail responds that the >users does exist, then Postfix will receive and relay the message to IMail? yes >If this is correct, does Postfix query IMail every time it receives a >message for the same user on the IMail server or does it store the result of >the first query in a local database that has some expiration rule applied to >it? no, it caches both negative and positive probe answers in a file, the same file for both recipients and senders. >If this is all correct, that's very cool. How has this feature been working >for you? SAV and RAV both work fine, and ime, are scaleable to the cache file having serveral 100K records. One can always delete this file and start over, but I haven't bothered so far. Len
