Recipient verification method flawed

Maybe I'm not seeing where server and mailer and Astaro are relative to each other, but I don't think the SMTP Proxy works the way I understand what you're saying.

Cheers - Bob

Bob,

I run my own mail server on my home network, and run the ASG's SMTP proxy in transparent mode in front of it.  Incoming mail is thus checked by the ASG proxy before it's delivered to my server - a process which works perfectly 99.999% of the time.

The problem appears to be that ASG uses a bounce check when verifying recipient addresses against the destination server, and Mailtraq does not recognize mailing lists or aliases as valid bounce recipients.

Here's an example from earlier today.  The "***and***" address is an alias that sends to both users *** and ***.

2010:07:27-09:50:18 astaro exim[4927]: 2010-07-27 09:50:18 SMTP connection from [74.125.82.172]:50021 (TCP/IP connection count = 1)

2010:07:27-09:50:19 astaro exim[8608]: 2010-07-27 09:50:19 [74.125.82.172] F= R= Verifying recipient address with callout

2010:07:27-09:50:19 astaro exim[8608]: 2010-07-27 09:50:19 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="74.125.82.172" from="******%40gmail.com" to="***and***%40snikte.net" size="-1" reason="address_verification" extra="Address unknown"

2010:07:27-09:50:19 astaro exim[8608]: 2010-07-27 09:50:19 H=mail-wy0-f172.google.com [74.125.82.172]:50021 F= rejected RCPT : response to "RCPT TO:" from blackbox.snikte.net [192.168.0.9] was: 550 invalid bounce recipient

2010:07:27-09:50:19 astaro exim[8608]: 2010-07-27 09:50:19 SMTP connection from mail-wy0-f172.google.com [74.125.82.172]:50021 closed by DROP in ACL

and here's the same exchange from the mail server's perspective:

+ 0000000F eccles.tzo.net (192.168.0.1) [7/27/2010 9:50 AM]

00000001 0000000F 27/07/2010 09:50:19 HELO eccles.tzo.net  --->  250 eccles.tzo.net  

00000001 0000000F 27/07/2010 09:50:19 MAIL FROM:<>  --->  250 no return address given  

00000001 0000000F 27/07/2010 09:50:19 Bouncing mail from  to ***and***@snikte.net

00000001 0000000F 27/07/2010 09:50:19 RCPT TO:  --->  550 invalid bounce recipient  

00000001 0000000F 27/07/2010 09:50:19 QUIT  --->  221 have a nice day (SMTP Closing)  

00000001 0000000F 27/07/2010 09:50:19 SMTP Client Disconnected (192.168.0.1): No DATA

- 0000000F

Since the incoming mail is not a bounce, I believe it's poor practice to be checking the destination address with a bounce query, though I have no idea what - if anything - the relevant RFC has to say about it.

OK, further clarification needed.  It appears that ASG tests for valid addresses by issuing a MAIL FROM with a blank address, followed by a RCPT TO with the address in question.  Mailtraq interprets this combination as a bounce, though again I don't know if that's specified in an RFC or is unique to Mailtraq.

But I have subsequently discovered that rejecting non-user addresses as bounce recipients is a selectable behavior in Mailtraq, designed to mitigate backscatter - see Backscatter Mitigation in the Mailtraq email server.  Disabling that option causes Mailtraq to accept any valid address - whether a real user or a distribution list - as a valid recipient even if the sender is blank.  I've turned it off for now, but I'd be happier if ASG didn't probe addresses with a blank FROM.

I understand now - I thought you thought the Astaro was doing recipient verification on email sent from inside the local network, but you really are talking about inbound email.

I don't know what the standard is.  It works fine with Exchange, and that's the only mail server I really know anything about.

Another thought... Have you tried changing your distribution addresses to something like Jim-and-Jill-list@domain.com and then putting the list@domain.com pattern into 'Mail Security >> Quarantine Report', 'Exceptions' tab, 'Define internal mailing lists'?

Cheers - Bob

I don't think that setting has any bearing on recipient verification - AFAIK it only causes ASG to prompt for a single recipient when releasing spam from the quarantine - but thanks for the reminder.