Authenticated users sending from blacklisted IP's

rokeeffe265 · ‎02-12-2009

Hi Guys,

I've read quite a few posts here about allowing 'good users' send from blacklisted IP's. Most of the solutions involve creating a rule for the ip and user.

I'm just wondering is there a more elegant catch all solution. The scenario we are in is as follows.

Our organisation sees a lot of our members travelling and sending mail from hotels, road side cafés, or USB 3G dongles (mobile devices). Some also live abroad and work from home.
At any one time there could be 40-50 users off site at conferences or in transit to or from various seminars.

As a consequence quite a few of them cannot send mails as they inevitably find themselves trying to send from blacklisted IP's.
I have the SBRS set to block from -10 to -6. I don't think this is overly aggressive, and I'm not keen on relaxing this any further than it already is.

It's not an option to constantly add IP's and users to and from rules as most of my day would be filled with requests just for this.

Is it a just matter of changing Connection Behaviour from 'Reject' to 'Continue' for the Blocked Mail Flow Policy?

I feel I'm missing something simple here :oops:

R.

steven_geerts · ‎02-13-2009

Hi Roen,

I think you can simply add another listener to your config (on another IP or on another TCP port) that listener can be configured for authenticated access only, without using Senderbase.
After that you only have to inform your roaming user to reconfigure their outbound mail setup so that they start using the new listener.

Thinking of this, I think you better use an alternative TCP port than an extra IP on TCP25. Many providers nowadays block outgoing traffic on TCP25. If you use an alternative port you omit those blocking rules.

Good luck, Steven

ecotricity_ironport · ‎02-17-2009

Hi Roen

I have exactly this same problem myself at the moment. Obviously to continually maintain the IP address in the whitelist is impossible, given that the majority of users, even if only sending from home, are unlikely to have static IP addresses.

The workaround I thought of was as Steven has suggested (to set up a new listener on a random non-standard port); however, the support team at our reseller have assured us that the Ironport should in fact automatically relay any authenticated users. The problem at our end is that the Ironport is not currently requesting authentication, and our users are being blocked by reputation filtering.

I do not yet have a solution to this, but it has been escalated to Ironport and I will update this thread as soon as I get a resolution.

Matt

rokeeffe265 · ‎02-20-2009

Hi guys,

thanks for all the responses. I'm sure this can be worked out.

Kind regards,
R.

ecotricity_ironport · ‎03-12-2009

Hi Guys

I finally have a resolution to this problem, which was provided by IronPort support.

The sender will be classified into the appropriate HAT sender group based on SBRS as normal and will be subject to any mail flow rate limiting that has been set up. This can not be avoided unless you want to set up a new listener and/or interface specifically for SMTP Auth traffic.

However, if a sending host matches the Blacklist and the sender is using SMTP Auth, there is a way to still allow them to send the message. To do this you can enable the Delayed HAT rejection on the listener. This delays the normal rejection due to the Blacklist until the sender has a chance to authenticate. Then they can send their message.

To enable this, log into the CLI and run the listenerconfig command then choose setup. You can press Enter to accept the current value for each choice until you see the setting:
'By default connections with a HAT REJECT policy will be closed with a banner message at the start of the SMTP conversation. Would you like to do the rejection at the message recipient level instead for more detailed logging of rejected mail? [N]>'. Choose Y for this. Press Enter the rest of the way through until you return to the main command prompt. Then type commit to save the change.

I can confirm that I have tested this and it has resolved the issue. :D

Matt