[quote user="Rolf Lindby"]To allow for local users connecting from the Internet and authenticating use operation D instead of H in the rule.[/quote]

*Facepalm* I could not see for looking. Thanks!

Hi

We presently use Mercury/32 to manage mail for three domains. Our mail passes through a 3rd party filtering service.

We use Google Apps GMail for staff that are out of the office and who need to work in local authority offices. This is because the local authority will not allow IMAP connections. GMail is configured so that mail is routed via our server which allows us to make and keep a copy of all messages sent. But - GMail does not allow an SMTP password to be entered as part of the 'remote gateway' setup.

We also allow certain staff to access their mail from home or on the move via IMAP.

SMTP>Relaying control is configured as follows to allow GMail to relay mail via our server: 

Use strict local relaying restrictions is checked

Authenticated SMTP connections may relay mail is checked

Only Authenticated SMTP connections my relay mail is not checked 

The other problem I have is that in order for staff to relay mail via our server from their home computers we need to configure Mercury/32 to allow connections from any source. This is because staff that use IMAP do not have static IP addresses, which would allow me to add those addresses to the Connection Control section of Mercury's SMTP configuration.

However, today one of our staff received a message containing malicious code. The message headers have our postmaster address as the sender address. The message originated from an external IP. I've appended the headers below.

I'm not really sure how to proceed. I need to keep all connections open for staff IMAP access and I also cannot allow only authenticated relaying because Google Apps does not make provision for entering an SMTP password.

Does anyone have any suggestions for me, please? I've not had to go down this route before so am out of my depth.

Thanks. 

*********************************************************************************************************

05:28:16.861: Connection from 122.144.10.242, Thu Apr 17 05:28:16 2014<lf>

05:28:16.861: << 220 **our-domain**.co.uk ESMTP server ready.<cr><lf>

05:28:16.080: >> EHLO **our-domain**.co.uk<cr><lf>

05:28:16.080: << 250-**our-domain**.co.uk Hello **our-domain**.co.uk; ESMTPs are:<cr><lf>250-TIME<cr><lf>

05:28:16.080: << 250-SIZE 0<cr><lf>

05:28:16.080: << 250-AUTH CRAM-MD5 LOGIN<cr><lf>

05:28:16.080: << 250-AUTH=LOGIN<cr><lf>

05:28:16.080: << 250 HELP<cr><lf>

05:28:18.406: >> MAIL FROM:<postmaster@**our-domain**.co.uk><cr><lf>

05:28:18.406: << 250 Sender OK - send RCPTs.<cr><lf>

05:28:18.624: >> RCPT TO:<user@**our-domain**.co.uk><cr><lf>

05:28:18.624: << 250 Recipient OK - send RCPT or DATA.<cr><lf>

05:28:18.842: >> DATA<cr><lf>

05:28:18.858: << 354 OK, send data, end with CRLF.CRLF<cr><lf>

05:28:18.061: >> From: "The Post Office" <postmaster@**our-domain**.co.uk><cr><lf>

05:28:18.076: >> To: user@**our-domain**.co.uk<cr><lf>

05:28:18.076: >> Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL<cr><lf>

05:28:18.076: >> Date: Thu, 17 Apr 2014 10:25:24 +0600<cr><lf>

05:28:18.076: >> MIME-Version: 1.0<cr><lf>

05:28:18.076: >> Content-Type: multipart/mixed;<cr><lf>

05:28:18.076: >> boundary="----=_NextPart_000_0001_45AB10F8.B838EC9C"<cr><lf>

05:28:18.076: >> X-Priority: 3<cr><lf>

05:28:18.076: >> X-MSMail-Priority: Normal<cr><lf>

05:28:18.076: >> X-Mailer: Microsoft Outlook Express 6.00.2600.0000<cr><lf>

05:28:18.076: >> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000<cr><lf>

05:28:18.076: >> <cr><lf>

05:28:18.076: >> This is a multi-part message in MIME format.<cr><lf>

05:28:18.076: >> <cr><lf>

05:28:18.076: >> ------=_NextPart_000_0001_45AB10F8.B838EC9C<cr><lf>

05:28:18.076: >> Content-Type: text/plain;<cr><lf>

05:28:18.076: >> charset=us-ascii<cr><lf>

05:28:18.076: >> Content-Transfer-Encoding: 7bit<cr><lf>

05:28:18.076: >> <cr><lf>

05:28:18.076: >> Dear user of **our-domain**.co.uk,<cr><lf>

05:28:18.092: >> <cr><lf>

05:28:18.092: >> We have detected that your email account was used to send a huge amount of spam during this week.<cr><lf>

05:28:18.092: >> Probably, your computer had been compromised and now contains a trojan proxy server.<cr><lf>

05:28:18.092: >> <cr><lf>

05:28:18.092: >> We recommend that you follow the instructions in the attached text file in order to keep your computer safe.<cr><lf>

05:28:18.092: >> <cr><lf>

05:28:18.092: >> Best wishes,<cr><lf>

05:28:18.092: >> **our-domain**.co.uk support team.<cr><lf>

05:28:18.092: >> <cr><lf>

05:28:18.092: >> <cr><lf>

05:28:18.092: >> ------=_NextPart_000_0001_45AB10F8.B838EC9C<cr><lf>

05:28:18.092: >> Content-Type: application/octet-stream;<cr><lf>

05:28:18.092: >> name="tftmth.zip"<cr><lf>

05:28:18.092: >> Content-Transfer-Encoding: base64<cr><lf>

05:28:18.092: >> Content-Disposition: attachment;<cr><lf>

05:28:18.092: >> filename="tftmth.zip"<cr><lf>

05:28:18.092: >> <cr><lf> 

If messages are for local recipients it's not a relaying issue, so we won't have to worry about those settings. To stop the malicious messages you could perhaps use transaction filtering in MercuryS to block the spoofed HELO/EHLO greeting (05:28:16.080: >> EHLO **our-domain**.co.uk<cr><lf>). Additionally, it could be possible to catch the attached zip files with Clamwall.

Thanks a lot, Rolf.

Would you be able to help with the format of the transaction filter, please? I have read through the section in the manual 'Compliance Options' about this, but am unsure of how to implement it as the domain name is the same as that of our system. I don't know what the difference in processing is between local mail and external mail. I have encouraged everyone to use the full address when sending local mail (staff-name@ourdomain.com) so that Mercury makes a copy of it, so don't want to inadvertently stop legitimate mail.

The TRANSFLT.MER file contains the following transaction filter: H, "[EHeh][EHeh]LO +[0-9]+.[0-9]+.[0-9]+.[0-9]*", R, "554 Invalid HELO format" which is pre-configured, but I am unsure of how to tell Mercury to drop connections from mail servers that impersonate our domain name.

Thanks. 

On my server I use:

H, "[EHeh][EHeh]LO mydomain.se*", R, "554 Illegal HELO, connection refused."

H, "[EHeh][EHeh]LO mail.mydomain.se*", R, "554 Illegal HELO, connection refused."

These rules apply to the SMTP HELO greeting, not MAIL FROM or the From header in the message. Neither your domain name (mydomain.se) or the qualified host name of the server (mail.mydomain.se) should normally appear here. If you have multiple servers handling your domain where some of them handle other domains as well, you may need to set servers to use the full host name in their greetings (if they sometimes need to send on mail from one of your servers to another for a specific domain).

That's great, Rolf. Thank you very much.

We just use one server so this will be fine.

Thanks again for the help!

Cheers! 

We are starting to get these connections from other domains. Is there a way to block all domains except the one that filters our email?

The MX records for our domain only list the filtering providers' addresses. These other connections are being made directly to our IP address.

So, is possible to include a transaction filtering rule that will reject any connection that is not from *mailspamfiltering.com ? Or, is this something can be configured elsewhere in Mercury, please?

Thanks! 

If you want to refuse a connection that doesn't match a specific expression in transaction filtering in MercuryS you can set the action to R-N. If you use Mercury for sending messages from local users it might not be a good idea to only allow mailspamfiltering.com to connect though (unless local users always authenticate; if so use operation D in the filter rule). If you know IP addresses or IP ranges for all that should be allowed to connect it might be possible to block using connection control instead of transaction filtering.

[quote user="Rolf Lindby"]If you want to refuse a connection that doesn't match a specific expression in transaction filtering in MercuryS you can set the action to R-N. If you use Mercury for sending messages from local users it might not be a good idea to only allow mailspamfiltering.com to connect though (unless local users always authenticate; if so use operation D in the filter rule). If you know IP addresses or IP ranges for all that should be allowed to connect it might be possible to block using connection control instead of transaction filtering.[/quote]

Thanks a lot, Rolf

All our staff that connect remotely have to authenticate SMTP connections. They do not have static IP addresses. We use Google Apps GMail and have configured GMail's SMTP delivery IP ranges in Connection control so that they can relay via our server and are exempt from blacklisting. Local users do not authenticate.

I'd missed the optional N action in the documentation, thanks a lot for that.

- 

So, how about if:

We use Connection control to allow local IP's (192.168.0.1 - 192.168.0.254) to connect and configure the range so that they can relay mail, are exempt from transaction filtering and are whitelisted.

and set the following transaction filter rule:

H, "[EHeh][EHeh]LO *mailspamfiltering.com*", R-N, "554 connection refused." 

-

Would that work? 

Thanks!

As long as there aren't any other transaction filter rules that need to be applied to connections from the local IP range it looks like it should work. It's very possible that the mailspamfiltering.com MTA always uses EHLO in the greeting so it might actually not be necessary to allow HELO.

Thanks a lot, Rolf

There are no transaction rules applied to local mail.

I'll exempt Google's and our spam filtering service IP addresses from transaction filtering and pop this rule into the list.

Thanks again. You've been a great help. 

Unfortunately, that is not working as expected. Staff that try to send messages when away from the office are having their connections refused. As stated above all remote connections require authentication.

I tried adding rules using the M operation and defining the domains we use and suppressing further transaction processing but the H rule is still active:

M, "*domain1.co.uk*" S
M, "*domain2.org*" S
H, "[EHeh][EHeh]LO *mailspamfiltering.com*", R-N, "554 connection refused." 

When I try to send a mail message from my home machine MercuryS refuses the connection: 

Connection from 12.23.56.78, Sat Jun 07 08:43:02 2014
EHLO [192.168.1.100]
554 connection refused.

Here's the full mer file:

H, "*80.45.49.93*", R, "554"
R, "*honeypot@aphrodite.pmail.gen.nz*", RS, "554 Fraudulent RCPT rejected."
S, "*viagra*", D, "'Viagra' encountered in subject line - connection dropped."
S, "*vicodin*", R, "554 'Vicodin' encountered in subject line - message refused."
M, "*@domain1.co.uk*" S
M, "*@domain2.org*" S
H, "[EHeh][EHeh]LO +[0-9]+.[0-9]+.[0-9]+.[0-9]*", R, "554 Invalid HELO format"
H, "[EHeh][EHeh]LO domain1.co.uk*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO mail.domain1.co.uk*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO domain2.org*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO mail.domain2.org*", R, "554 Illegal HELO, connection refused."
H, "[EHeh][EHeh]LO *mailspamfiltering.com*", R-N, "554 connection refused."
# S, "/c*CONGRATULATIONS*WON*", BS, "554 Possibly Nigerian 419 Variant - please change and re-send."
# S, "*for job*", BS, "554 Possibly employment spam - please change and re-send."

As soon as I comment out    H, "[EHeh][EHeh]LO *mailspamfiltering.com*", R-N, "554 connection refused."     connections from my home machine are allowed.

I'm obviously doing something wrong here but can't figure it out. Can anyone help me with this, please?

To allow for local users connecting from the Internet and authenticating use operation D instead of H in the rule.