Veirfy = Recipient Stopped Working

[mctDarren]

Well been searching for a bit now and can't find a specific post that helps with my problem. I'm running Chirpy's MailScanner config. Last week I had a client complain about sender/callout verify - it was blocking a domain they needed to get mail from, so I was forced to cancel it out:

 #sender verifications are required for all messages that are not sent to lists
  #require verify = sender/callout
  #accept  domains = +local_domains
  #endpass

While searching I also ran across the script to make sure all your domains are set to :fail:, which essentially means I ran this below, which I probably didn't need to do but nice to be sure all are set to :fail: --

replace :blackhole: :fail: -- /etc/valiases/*

Now today I noticed that my queue has bounce messages lurking in there from failed addresses, meaning mail to a non-existent address that for whatever reason has caused Exim sent out a bounce msg! I checked exim.conf and verify=recipient (with message) is in there.

message = "The recipient cannot be verified. $acl_verify_message"
  verify = recipient

Checking my valiases they all look like this example:

[email protected]_domain.com: [email protected]_domain.com
*: :fail:

Checking exim_mainlog when testing from an outside source I see this (with emails/ips changed to protect the not-so-innocent):

2006-09-18 11:21:36 SMTP connection from [x.x.x.x]:62852 I=[x.x.x.x]:25 (TCP/IP connection count = 1)
2006-09-18 11:21:37 1GPKwD-0003j0-3K <= [email protected] H=(ISP) [x.x.x.x]:62852 I=[x.x.x.x]:25 P=esmtp S=1040 id=ISPID T="[Fwd: Testing email]" from <[email protected]> for [email protected]_domain.com
2006-09-18 11:21:37 SMTP connection from (ISP) [x.x.x.x]:62852 I=[x.x.x.x]:25 closed by QUIT
2006-09-18 11:21:40 cwd=/var/spool/MailScanner/incoming/9984 5 args: /usr/sbin/exim -C /etc/exim_outgoing.conf -Mc 1GPKwD-0003j0-3K
2006-09-18 11:21:40 1GPKwD-0003j0-3K ** [email protected]_domain.com F=<[email protected]> R=virtual_aliases:
2006-09-18 11:21:40 cwd=/var/spool/exim 9 args: /usr/sbin/exim -C /etc/exim_outgoing.conf -t -oem -oi -f <> -E1GPKwD-0003j0-3K
2006-09-18 11:21:40 1GPKwG-0003jA-CQ <= <> R=1GPKwD-0003j0-3K U=mailnull P=local S=2180 T="Mail delivery failed: returning message to sender" from <> for [email protected]
2006-09-18 11:21:40 cwd=/var/spool/exim 5 args: /usr/sbin/exim -C /etc/exim_outgoing.conf -Mc 1GPKwG-0003jA-CQ
2006-09-18 11:21:40 1GPKwD-0003j0-3K Completed QT=3s

Now I see in there on the line where it looks like its trying to route through "virtual_aliases" and there is no result. Checking virtual_aliases, it looks like this:

virtual_aliases:
  driver = redirect
  allow_defer
  allow_fail
  data = ${if exists{/etc/valiases/$domain}{${lookup{*}lsearch{/etc/valiases/$domain}}}}
  file_transport = address_file
  group = mail
  pipe_transport = virtual_address_pipe
  domains = lsearch;/etc/localdomains
  retry_use_local_part

Confuzzled. I see an "allow_fail" line - is that what should cause it fail? I'm sure I muxed up something here, but not sure what. I probably should delve alot more into the inner workings of how fail executes and trace it through, but I just don't have the time right now. Anyone have any ideas? Thanks in advance!

EDIT: As an aside, I did run "/scripts/eximup --force" to see if that would help but did not. Another user tells me that he has some filters in place on his domain to stop bounce messages from a spammer using his domain as the return mail in spam - and those filters have stopped working for some reason. Exim.conf error must be the cause of this....

 

[rvskin]

You have mixed up the ACL.

#sender verifications are required for all messages that are not sent to lists
#require verify = sender/callout
#accept domains = +local_domains
#endpass

Change above to

#sender verifications are required for all messages that are not sent to lists
#require verify = sender/callout
accept domains = +local_domains
endpass

 

[mctDarren]

aha! Thanks will fix that. Weird that the bottom two lines were indented immediately under the verify line - thought it was all in one statement. :D

Thanks!

 

[RickG]

I understand the predicament but hate to see you disable the sender verify function completely as it does help cut down on spam.

1) You could leave it enabled as you have it set but create a whitelist that you update when advised of a problem. False positives and timeouts do happen particularly if the legitimate senders server is extemely busy (or more often misconfigured). There are very good instructions in this thread (which if you follow, read the whole thing first as there are some corrections towards the end):
http://forums.cpanel.net/showthread.php?p=215336#post215336

2) The other options is to use a "kinder gentler" version of the sender verify function. You have it set: require verify = sender/callout which (in simple terms) means you are trying to verify the senders full email account exists. Setting this to: require verify = sender (without the callout) will at least reject mail where the domain is completly spoofed, and in that scenario you'll hardly ever see a false positive and IMHO won't need a whitelist.

3) The third option is to leave things as is but increase the timeout value such as sender/callout=45s (the default is 30s if you do not specify anything - don't bump up too high).

Just some additional options to consider.

 

[mctDarren]

Rick, thanks for the advice. I actually did see the thread with the whitelist suggestion, but wanted to get the email flowing for the customer first.

The thing that makes me so angry about this is that the client is getting paid notifications from a major US bank via this email, and their servers aren't config'd correctly. Even without the callout it fails because they actually spoof the domain in the email!!

I sent them an email 10 days ago, so I might not even be getting a reply. I might move this client to a VPS on their own so I can control their email a little more tightly without making spam worse for the other clients on the box. Frustrating!!

But thanks so much for the suggestions.