Caching dial-out recipient verification?

I'm not sure what you mean.  If this is about outbound email, have you tried clearing the DNS cache?  Before V7.500, there's no button to do that, so you have to disable then re-enable the DNS Proxy.

Cheers - Bob

Bob,

I'll try and describe this case again...

Our mail setup is an ASL box (DELL PowerEdge) hung in front of another linux box with an mail aliases file. The ASL is configured to receive the mails, check for spam and such, and forward it to the linux box.

Before accepting any inbound mails, it checks (SMTP dial-out) whether the recipients do exist. Now we had a typo in the aliases file which made the box (rightfully) check, get a "recipient does not exist" error and therefor bounce a test mail. We corrected the typo and... still bouncing.

Looking into the logs on the linux box behind the ASL I don't see any connections to check whether that recipient is valid or not; the ASL seems to cache that info...

I don't know of any such cache... What do you see in the Mail Manager SMTP Log relative to the test email?

Same here:
RCPTs have internally been rejected because of Domino misconfig; having corrected the error, but still "RCPT Unknown"

tcpdump reading all SMTP traffic to internal host shows: NO TRAFFIC at all when sending to this RCPT.

--> there MUST be a cache. WHERE? 
Disabling and RE-Enabling RCPT Verification: No effect!
Disabling and RE-Enabling the whole SMTP Proxy: No effect!

Can someone from Astaro verify this?!?
TIA
M. Hock

Creating a new Exception list containing the cached addresses obviously solves this problem - more interesting might be that even after deleting this exception list again the cache does not block the addresses any more.
A "Clear cache" button would be a lot more comfortable though.

@ Astaro: it possible to get a statement to this behaviour? A console command to clear the cache would be enough, we dont need a button for every action ;-)

try:
/var/mdw/scripts/smtp stop
rm -rf /var/chroot-smtp/tmp/ram/db_input/callout*
/var/mdw/scripts/smtp start

Ölm to the rescue again!

Do you have any idea what the "lifetime" is of individually cached names?

Thanks - Bob

From the exim´s user manual:

  39.33 Callout caching 

  Exim caches the results of callouts in order to reduce the amount of resources used, unless you specify the no_cache parameter with the callout option. A hints database called “callout” is used for the cache. Two different record types are used: one records the result of a callout check for a specific address, and the other records information that applies to the entire domain (for example, that it accepts the local part postmaster). 
  When an original callout fails, a detailed SMTP error message is given about the failure. However, for subsequent failures use the cache data, this message is not available. 
  The expiry times for negative and positive address cache records are independent, and can be set by the global options callout_negative_expire (default 2h) and callout_positive_expire (default 24h), respectively. 
  If a host gives a negative response to an SMTP connection, or rejects any commands up to and including 
  MAIL FROM:<>
  (but not including the [SIZE=-1]MAIL[/SIZE] command with a non-empty address), any callout attempt is bound to fail. Exim remembers such failures in a domain cache record, which it uses to fail callouts for the domain without making new connections, until the domain record times out. There are two separate expiry times for domain cache records: callout_domain_negative_expire (default 3h) and callout_domain_positive_expire (default 7d). 
  Domain records expire when the negative expiry time is reached if callouts cannot be made for the domain, or if the postmaster check failed. Otherwise, they expire when the positive expiry time is reached. This ensures that, for example, a host that stops accepting “random” local parts will eventually be noticed.

There are not options "callout_negative_expire" or "callout_positive_expire" in the exim.conf files on the ASG , so I think the default values of 2h respectivley 24h are used.

Hi Ölm,

haven't tried it yet, but sounds plausible, thanks a lot!

BTW, I think 2h callout_negative_expire timeout might be a little high, especially as long as there is no "clear cache" button to tell ASG one has corrected the typos in the internal mailserver usernames [:)]

Great idea for a feature suggestion: Astaro Gateway Feature Requests.

Cheers - Bob