[7.001] No Verify recipient anymore?

I'm sure they took it out, because spammers found a way to use it to their advantage...  I've had to disable it on most of my V6 installations.

Bruce, you must be confusing the "Verify Recipient" feature with the "Verify Sender" feature as the "Verify Recipient" feature is VERY useful as it prevents backscatter and prevents illegitimate email from being received in the first place.

I'm going to have to test this, as if the SMTP proxy doesn't validate the recipient and instead generates bounces for invalid recipients, that makes you very likely to appear on various RBL blacklists for having a misconfigured mail server.

Hi drees,
I agree with you...

I just tested it, looks like it verifies the recipient by default which is good. [:)]

Although, before I entered a valid gateway on the system it didn't verify the recipient which had me confused for a while.

No, I'm not confused, it was the Verify RCPT option that I am thinking about.  All I know is Astaro Support told me it was a bad idea to have it on.. after they explained why, it made perfect sense.  Mail servers sometimes send NDRs when the Verify RCPT is run; a spammer could randomly generate email addresses, and when they didn't get an NDR back, they would know they had a valid address... automate that, and suddenly your Astaro is flooded with requests.. I had this happen to a customer with a 220, and it brought it to it's knees.

---hmmm just read what drees just posted.. interesting... Astaro Support must've been wrong, or is not heeding their own advice to me.  All I know is that once that was turned off, the traffic gradually went down.

Hi BrucekConvergent,
I agree with you too :-)
Maybe Astaro should say what they have done in V7
and if it is configurable or not...

No, I'm not confused, it was the Verify RCPT option that I am thinking about.  All I know is Astaro Support told me it was a bad idea to have it on.. after they explained why, it made perfect sense.  Mail servers sometimes send NDRs when the Verify RCPT is run; a spammer could randomly generate email addresses, and when they didn't get an NDR back, they would know they had a valid address... automate that, and suddenly your Astaro is flooded with requests.. I had this happen to a customer with a 220, and it brought it to it's knees.

---hmmm just read what drees just posted.. interesting... Astaro Support must've been wrong, or is not heeding their own advice to me.  All I know is that once that was turned off, the traffic gradually went down.

All spammers generate random email addresses when sending mail. All my email servers are constantly bombarded by emails destined for non-existent email addresses 24 hours a day.

It takes next to no resources and bandwidth to stop a SMTP transaction for an email destined for a non-existent user.

All the firewall has to do is check with the destination server whether the user is valid, if it's not, REJECT the message immediately. The firewall can then cache these results for some period of time to avoid multiple redundant lookups.

If the firewall does not validate the recipient, now it has to store the message, scan the message (if you have virus/spam scanning on) and then attempt to deliver the message which will immediately be rejected by the destination server. This takes a LOT more resources than rejecting it without doing any of the resource intensive scanning. And now the firewall should generate a bounce message letting the sender know the message was not delivered. This means more bandwidth and since 999 times out of 1000 the sender address was either randomly generated or spoofed, this means the bounce will either not be deliverable or will be delivered to someone who doesn't care.

Trust me, Verify Recipient is GOOD. It stops backscatter and saves resources. Everyone should have it on except in special cases where it's not possible to verify the recipient.

Saying that turning it off reduces SPAM by allowing spammers to find "good" email addresses is crazy. The spammers will find valid email addresses one way or another, not verifying the recipient will not stop them.

Verifying the Sender is also often good, but not always since many emails are sent with a non-deliverable sender.

Very simply... with an Astaro 220 on a fractional T1 interface, with the 20 concurrent connection limit set, I've seen the Load and Swap go into outer space.  And these were connections that were 95% dropped immediately due to RBL, no resources there... except multiple instances of exim and spamd were eating the machine alive.  The official stance of the support person I got was that the RCPT thing was bad (not the reason for the issue, but just as an aside) ... we ended up manually lowering the allowed connection rate to 8.  I'm just repeating what Astaro told me... nothing more.  Disabling the RCPT function has caused no appreciable / detectable increase in spam at any of my customer sites.  Just based on what I was told, it seemed reasonable to me that they would've eliminated that option.  What I would like to see would be Bayesian filtering enabled...

By enabling Verify Recipient, you reduce load, not increase it.

If support said verifying the recipient is bad, they are wrong. If it's bad on Astaro, there is a bug in Astaro. All my Astaro firewalls have Verify Recipient enabled on them and have never experienced a load issue because of it.

Disabling Verify Recipient does not increase spam at your customer sites, it causes backscatter which can cause your customer sites to be listed by RBL blacklists since you are making the spam problem worse for everyone else. See here for more information on backscatter: http://en.wikipedia.org/wiki/Backscatter#Backscatter_of_email_spam

I just tested it, looks like it verifies the recipient by default which is good. [:)]

Although, before I entered a valid gateway on the system it didn't verify the recipient which had me confused for a while.

To me it seems that Verify recipient feature is *NOT* turned on?

Look at this log: 

2007:02:07-08:35:11 (none) exim[10531]: 2007-02-07 08:35:11 SMTP connection from [192.168.***.***]:1729 (TCP/IP connection count = 1)

2007:02:07-08:35:12 (none) exim[11564]: 2007-02-07 08:35:12 [pid 11564] [192.168.***.***] F= Trusted (sent from relay or localhost)

2007:02:07-08:35:12 (none) exim[11564]: 2007-02-07 08:35:12 [pid 11564] [192.168.***.***] F= R= Accepted: from relay

2007:02:07-08:35:12 (none) exim[11564]: 2007-02-07 08:35:12 1HEhKi-00030W-3P  unknown@recdomain.com F= P= R=cff_route T=cff_smtp H=127.0.0.1 [127.0.0.1]:1234

2007:02:07-08:35:12 (none) exim[11565]: 2007-02-07 08:35:12 1HEhKi-00030W-3P Completed

2007:02:07-08:35:15 (none) exim[11572]: 2007-02-07 08:35:15 SMTP connection from MailerDaemon

2007:02:07-08:35:15 (none) exim[11572]: 2007-02-07 08:35:15 1HEhKl-00030e-Ld  P= R=static_route_hostlist T=static_smtp: SMTP error from remote mail server after RCPT TO:: host 192.168.YYY.YYY [192.168.YYY.YYY]: 550 No such recipient

2007:02:07-08:35:15 (none) exim[11578]: 2007-02-07 08:35:15 1HEhKl-00030k-Sv <> R=1HEhKl-00030e-Ld U=exim P=local S=108534

2007:02:07-08:35:15 (none) exim[11573]: 2007-02-07 08:35:15 1HEhKl-00030e-Ld Completed

2007:02:07-08:35:16 (none) exim[11579]: 2007-02-07 08:35:16 1HEhKl-00030k-Sv => fromuser@domain.com F=<> P=<> R=cff_route T=cff_smtp H=127.0.0.1 [127.0.0.1]:1234

2007:02:07-08:35:16 (none) exim[11579]: 2007-02-07 08:35:16 1HEhKl-00030k-Sv Completed

2007:02:07-08:35:18 (none) exim[11597]: 2007-02-07 08:35:18 SMTP connection from MailerDaemon

2007:02:07-08:35:18 (none) exim[11597]: 2007-02-07 08:35:18 1HEhKo-000313-Rj <> U=MailerDaemon P=local-bsmtp S=108728 id=E1HEhKl-00030k-Sv@asl7.recdomain.com

2007:02:07-08:35:19 (none) exim[11598]: 2007-02-07 08:35:19 1HEhKo-000313-Rj => fromuser@domain.com F=<> P=<> R=smarthost_route T=remote_smtp H=192.168.ZZZ.ZZZ [192.168.ZZZ.ZZZ]:25 X=TLSv1:AES256-SHA:256

2007:02:07-08:35:19 (none) exim[11598]: 2007-02-07 08:35:19 1HEhKo-000313-Rj Completed

ASL Accepts the Mails and then generates a Mail Delivery failure Message?