[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.

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?

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

Look at this log: 

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)

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

I suspect it doesn't bother with verifying the recipient in this case as you are sending the message from a trusted host.

Hi drees,
my mistake. So Verify Recipient is *ON* in ASL 7.001!

Hi,

this seems to be a confusing issue. [:)]

1) Sender verification has been completely removed in V7. The reason is that it creates too much collateral damage. Most spammers now use valid return-paths for their spam. In contrast, many legit automated mailing services still use return-paths that do not accepts bounces (NDRs).

2) Recipient verification is ALWAYS on in V7. You should configure your backend in such a way that it does NOT accept mail to invalid addresses. The ASG will "copy" the backend responses 1:1. If the backend accepts a recipient, ASG will accept it too. If the backend rejects a recipient, ASG will reject it too.

HOWEVER: Recipient verification is NOT done for trusted (authenticated) or relay hosts, because some user agents have problems when recipients get rejected in the SMTP transaction (@Sven: your test was done from a relay host).

As drees has pointed out there is no reason NOT to enable recipient verification. The argument that spammers can run dictionary attacks is mostly bogus: If you accept every address they have already delivered their crap and have won. You'll have to cope with a shitload of spam, gaining nothing.

/tom

Hi,

this seems to be a confusing issue. [:)]

1) Sender verification has been completely removed in V7. The reason is that it creates too much collateral damage. Most spammers now use valid return-paths for their spam. In contrast, many legit automated mailing services still use return-paths that do not accepts bounces (NDRs).

2) Recipient verification is ALWAYS on in V7. You should configure your backend in such a way that it does NOT accept mail to invalid addresses. The ASG will "copy" the backend responses 1:1. If the backend accepts a recipient, ASG will accept it too. If the backend rejects a recipient, ASG will reject it too.

HOWEVER: Recipient verification is NOT done for trusted (authenticated) or relay hosts, because some user agents have problems when recipients get rejected in the SMTP transaction (@Sven: your test was done from a relay host).

As drees has pointed out there is no reason NOT to enable recipient verification. The argument that spammers can run dictionary attacks is mostly bogus: If you accept every address they have already delivered their crap and have won. You'll have to cope with a shitload of spam, gaining nothing.

/tom

Thanks for verifying everything I've been trying to say this whole thread, tom. [:)]

-Dave

Interesting thread. Nice to get some more knowledge regarding this subject.

But, is there a way to prevent the firewall from bouncing a message back to the sender if the recipient address is rejected?

eirik

But, is there a way to prevent the firewall from bouncing a message back to the sender if the recipient address is rejected?

In the usual scenario (Backend reject unknown recipients in the SMTP transaction),  ASG will only generate bounces:

1) When a trusted or relay source sends to undeliverable recipients.
2) When the backend has been down, so ASG could not verify the recipients.

ASG does not prevent your backend servers sending NDRs/bounces, however.

/tom

OK. Then I don't understand why I get a bounce message when I send a test mail from work to a "unknown recipient" on the mailserver (which is at home).

The bounce message I get is:

This message was created automatically by the SMTP relay on firewall.yyy.com.

  

A message that you sent could not be delivered to all of its recipients.

The following address(es) failed:



  aaa@yyy.com

    SMTP error from remote mail server after RCPT TO::

    host 192.168.***.*** [192.168.***.***]: 550 :

    Recipient address rejected: User unknown in local recipient table

Where "firewall.yyy.com" is my Astaro firewall and "aaa" is the unknown recipient.

As said before: Astaro does not validate the recipient for trusted hosts/networks.

As said before: Astaro does not validate the recipient for trusted hosts/networks.

Maybe that I'm stupid or just completly lost (I guess the last one), but my work address is not a trusted host/network. Only my servers behind the Astaro firewall is listed as trusted host/network in the SMTP proxy.

I did take a look in the SMTP log with respect to the bounce message I included in the previous post. Here it what it said:

2007:02:08-22:55:40 (none) exim[27962]: 2007-02-08 22:55:40 SMTP connection from [65.***.***.***]:3661 (TCP/IP connection count = 1)

2007:02:08-22:55:41 (none) exim[16986]: 2007-02-08 22:55:41 [pid 16986] [65.***.***.***] F= Untrusted message

2007:02:08-22:55:41 (none) exim[16986]: 2007-02-08 22:55:41 [pid 16986] [65.***.***.***] F= R= Verifying recipient address

2007:02:08-22:55:41 (none) exim[16986]: 2007-02-08 22:55:41 [pid 16986] [65.***.***.***] F= R= Greylisting: skipped for this domain

2007:02:08-22:55:41 (none) exim[16986]: 2007-02-08 22:55:41 1HFHEz-0004Py-91  unknownuser@domain.org F= P= R=cff_route T=cff_smtp H=127.0.0.1 [127.0.0.1]:1234

2007:02:08-22:55:41 (none) exim[16987]: 2007-02-08 22:55:41 1HFHEz-0004Py-91 Completed

2007:02:08-22:55:43 (none) exim[16991]: 2007-02-08 22:55:43 SMTP connection from MailerDaemon

2007:02:08-22:55:43 (none) exim[16991]: 2007-02-08 22:55:43 1HFHF1-0004Q3-7a <> R=1HFHF1-0004Q3-7a U=exim P=local S=5290

2007:02:08-22:55:43 (none) exim[16992]: 2007-02-08 22:55:43 1HFHF1-0004Q3-7a Completed

2007:02:08-22:55:43 (none) exim[16997]: 2007-02-08 22:55:43 1HFHF1-0004Q8-BP => fromuser@domain.com F=<> P=<> R=cff_route T=cff_smtp H=127.0.0.1 [127.0.0.1]:1234

2007:02:08-22:55:43 (none) exim[16997]: 2007-02-08 22:55:43 1HFHF1-0004Q8-BP Completed

2007:02:08-22:55:45 (none) exim[17008]: 2007-02-08 22:55:45 SMTP connection from MailerDaemon

2007:02:08-22:55:45 (none) exim[17008]: 2007-02-08 22:55:45 1HFHF3-0004QK-Cb <> U=MailerDaemon P=local-bsmtp S=5490 id=E1HFHF1-0004Q8-BP@firewall.domain.org

2007:02:08-22:55:53 (none) exim[17009]: 2007-02-08 22:55:53 1HFHF3-0004QK-Cb => fromuser@domain.com F=<> P=<> R=dnslookup T=remote_smtp H=mail.emps.equant.com [207.***.***.***]:25 X=TLSv1[:D]HE-RSA-AES256-SHA:256

2007:02:08-22:55:53 (none) exim[17009]: 2007-02-08 22:55:53 1HFHF3-0004QK-Cb Completed

According to this it is recognised as untrusted. so why did I get the bounce message? It is not generated by the mailserver (according to what I can see).

Eirik

Ah. Well, for some reason Astaro thinks that the recipient address is valid. Was it valid at one time? Have you tried a different invalid address?

Again seconding what drees said:

ASG caches positive callout replies for 24 hours, and negative ones for 2 hours.

Was the address you tested this with valid in the last 24 hours?

Thanks for your replies.
No, the address wasn't and has never been valid. But, I didn't add "reject_unlisted_recipient" to "smtpd_recipient_restrictions" in postfix until a couple of days ago. Missed it when it configured the mailserver. Maybe that can have something to say why Astaro thinks this address is valid?

Is there a way to clean out the cache manually?

On other "unknown" addresses that I have tested randomly Astaro dosn't send a bounce message, only to the one address mentioned above.