Skip,

Chris's point is that your users **should** use SMTP authorization to distinguish their trusted connections from other connections that must be spam filtered. Additionally, you should NOT do ANY spam filtering on these SMTP Auth connections... especially not outright RBL blocking. You state that "the blacklists were rejecting connections to the MTA before SMTP"... but this **is** a misconfiguration on your part. You shouldn't allow rejecting of connections before you get a chance to determine whether the connection was SMTP AUTH or not.

In a sense, you are asking for something that is unreasonable... you want RBLs to block spam that is spewing out of zombie-infected computers... but, somehow, the DNSBL is suppose to know when YOUR users are attempting to send direct to your server from that same zombie computer... where the RBL isn't bypassed for SMTP AUTH connections.

This is a fundamental flaw in your architecture. Until you fix this, you'll get FPs with almost all of the best RBLs that other mail providers use on large networks every day with virtually zero FPs. The problem is your configuration, not with the RBLs.

Rob McEwen

Skip wrote:
From: Chris Edwards
Your travellers should be using one of:
- Authenticated SMTP submission bypassing your DNSBL tests
- VPN into your network
- Your webmail service

All of these are available.  Unless I somehow had something configured
improperly, the blacklists were rejecting connection to the MTA before SMTP
auth.  The second two are in place because of this very issue.  Users prefer
not to use webmail because it is inefficient.  A mail client (i.e. Outlook,
Thunderbird, etc.) has their address books and keeps better records of sent
mail.

While this has solved my issues with my travelling users, it does not
eliminate the FP issues.  And I am not willing to take that risk.  If there
is a communication breakdown due to a 3rd party falsely flagging a network,
that is not going to reflect on the 3rd party.  It will reflect on us and
results in the potential for lost business.

- Skip



Reply via email to