Thanks for that, Thomas. I've downloaded the text, and will have a look.

Cheers!

Hi Folks

I have a question about SMTP mail from allowed IP ranges.

All mail we receive goes through MessageLabs. This means that all email has a banner inserted at the end of the message stating it has been scanned by MessageLabs. Today we received an email which was classified as spam, and which did not include the banner.

The MercuryS log shows the following for the email:

T 20080318 042741 47df2244 Connection from 61.145.143.171
T 20080318 042743 47df2244 EHLO tom.com
T 20080318 042744 47df2244 RSET
T 20080318 042744 47df2244 MAIL FROM:<mcu_5@tom.com>
T 20080318 042745 47df2244 RCPT TO:<info@apsarchaeology.co.uk>
T 20080318 042747 47df2244 DATA - 41 lines, 1298 bytes.
T 20080318 042747 47df2244 QUIT
T 20080318 042748 47df2244 Connection closed with 61.145.143.171, 7 sec. elapsed.

As the banner was missing, I checked the originating IP address against the allowed range specified in the MercuryS configuration dialog.

I have the following ranges allowed in MercuryS:

62.173.108.16 62.173.108.31
62.173.108.208 62.173.108.223
62.231.131.0 62.231.131.255
85.158.136.0 85.158.143.255
117.120.16.0 117.120.23.255
192.168.0.5 192.168.0.5
192.168.0.70 192.168.0.70
193.109.254.0 193.109.255.255
194.106.220.0 194.106.221.255
195.245.230.0 195.245.231.255
212.125.75.0 212.125.75.31
216.82.240.0 216.82.255.255

Here's a screenshot of the IP configuration in MercuryS:

Here are the headers:

X-SPAMWALL: Passed through antiSPAM test by SpamHalter 4.3.1 on apsarchaeology.co.uk (42488)
X-SPAMWALL: probability - 100.0%
X-SPAMWALL: SPAM detected!
Return-path: <mcu_5@tom.com>
Received: from tom.com (61.145.143.171) by apsarchaeology.co.uk (Mercury/32 v4.52) with ESMTP ID MG000160;
   18 Mar 2008 04:27:46 -0000
Received: from YADA06[192.168.0.1] by tom.com
  with SMTP id 2DB87FE5; Tue, 18 Mar 2008 12:27:39 +0800
From: "mcu_5" <mcu_5@tom.com>
Subject: [SPAM01] Electronic PCBA module design & Assembly
To: "info" <info@apsarchaeology.co.uk>
Content-Type: text/plain;
 charset="gb2312"
Content-Transfer-Encoding: 8bit
Reply-To: mcu_5@tom.com
Date: Tue, 18 Mar 2008 12:28:16 +0800
X-Mailer: Foxmail 4.2 [cn]
X-PMFLAGS: 34078848 0 1 7C08280C.CNM

I don't understand how Mercury was able to accept the mail from 61.145.143.171 when it is outside the allowed range of IP addresses. Am I missing something here?

Is there any further configuration I need to carry out to ensure that Mercury only accepts SMTP connections from the allowed ranges?

All help will be gratefully accepted.

Thanks

[quote user="Greenman"]  

I don't understand how Mercury was able to accept the mail from 61.145.143.171 when it is outside the allowed range of IP addresses. Am I missing something here?

Is there any further configuration I need to carry out to ensure that Mercury only accepts SMTP connections from the allowed ranges?

[/quote]

It's not clear from here why the spammer even connected directly to your MTA - apsarchaeology.co.uk uses MessageLabs MXs, and the host apsarchaeology.co.uk doesn't run a public MTA.  The record must be cached by some ratware somewhere; in that case it should go away soon.

The MercuryS ACL consists in the allow and deny list (see the help for a full description).  The allow list specifies hosts allowed to send mail and optionally those allowed to relay when otherwise prohibitted by configuration.  Specifying an allow entry without relaying permission is useful because it allows you to override a more general deny entry, which does just that - ban outright any connection from that host.  However, it is otherwise assumed that all hosts are allowed to connect but not to relay (providing relaying control is correctly configured, of course).  That's a necessary assumption, of course - mail to local users must always be accepted, and your configuration is unusual in that respect.

To get the effect you want, simply ban every IP address on the internet (0.0.0.0 to 255.255.255.255).  It is then EXTREMELY IMPORTANT that you ensure EVERY HOST THAT DELIVERS MAIL TO YOUR HOST is allowed to do so.  Every allow range overrides the global ban.

Cheers,

Sabahattin

Hi Sabahattin

Thanks for your response.

As I understand it, I can simply ban all IP addresses and the rules I have in place at present will simply overide the ban where addresses are explicitly allowed? Does the global banned range need to be added at the top of the list, or does its position in the list not matter?

I don't understand what you have written about our configuration being unusual. What I thought had been configured was that Mercury would only accept SMTP deliveries from the address ranges specified (I was wrong), and that relaying from outside hosts is not allowed unless authorised. We have set up IMAP, allowing staff to send mail from home only if they enter the correct password which is contained in the SMTP_Auth.pw file.

Cheers!

Make sure the refuse is after all of the allow lines. FWIW, the allow lines are not excluding any other connecting host unless there is a refuse that includes this connecting IP address.

The allow line are there to allow connection that would otherwise be refused because the IP address is in a refuse entry.

Thanks for the clarification. This is something that is not made clear in the help file. Although the help file says that where overlapping ranges of deny and allow values exist, the allow range takes precedence, it would be useful if it was explained that all SMTP connections will be accepted unless specifically denied.

Cheers!

[quote user="Greenman"]

Thanks for the clarification. This is something that is not made clear in the help file. Although the help file says that where overlapping ranges of deny and allow values exist, the allow range takes precedence, it would be useful if it was explained that all SMTP connections will be accepted unless specifically denied.

[/quote]

The help file explains that whichever address range matches most specifically the connecting client's address results in the action associated with that rule being taken.  It also tells you that the ACL has two functions, partially deducible from fairly simple logic: any connection denied is denied from either sending mail and relaying by extension; and any connection allowed to relay must also be allowed to send mail by extension.  There exists the possibility to override a refusal by providing an allow entry that doesn't allow relaying using the most-specific selection rule so that the allowed hosts can still deliver local mail.  As such, allow entries are typically only used to grant special relaying privileges: it's silly to assume that the default action is to reject, since mail could never reach your site otherwise, but the reject action provides the means to suppress bad hosts.  Your configuration is strange because you *expect* not to get mail from any host other than trusted filter hosts, rather than the usual routine of denying bad hosts and giving relaying privileges to good ones (not counting authentication).  Perhaps the help could be clearer, but I think it's reasonably unambiguous as it stands.  Just read it again carefully.

Cheers,

Sabahattin

Thanks for that, I understand.

What I mean is that it depends on your level of experience. This is the first time we have managed our own SMTP receipt and delivery so it is a learning curve. Reading the help, we expected to only receive mail from the ranges specified. As you say, with hindsight, and knowing what we know now, re-reading the help shows this was wrong. It would be useful if there was a 'basics' paragraph so that 'first-timers' like us could protect our users more efficiently.

Cheers!

This is a major problem with any help.  If you try to provide the basics of how a protocol is supposed to work you'll never have have time to do anything but create help text.  What you really need to do is get some specifics on how a SMTP server is supposed to work from RFC 2821 or one of the 0'Riley books.  You can then use the Mercury/32 help to determine how this is implemented.