seeking anti-spam "best practices"
Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007)
libimta.so 6.3-0.15 (built 19:17:24, Feb 9 2007)
SunOS umduwc01 5.10 Generic_125101-05 i86pc i386 i86pc
This is a two-tiered environment using LMTP. I have MTA logging enabled on all channels (default).
I realize that techniques for anti-spam will vary by site, but I'm seeking some general advice.
Right now, all inbound mail appears first on tcp_intranet. I believe this is due to the firewall configuration, causing all message transfer to appear to be coming from this device's internal address. All external connections appeared to be internal.
My MTA was accepting transfers from these apparent internal addresses, and routing to external addresses (open relay). I think configuring the firewall address as external (in mappings?) will fix this, but I also want to configure the MTA to be more restrictive if possible.
I think the following makes sense, and I'd appreciate comments on the approach, as well as pointers on how to configure things this way.
1. Allow mail submission only on port 587, requiring authentication regardless of location of user (internal or external). No submission on port 25.
2. Accept mail on port 25 that is destined for internal users only. Accept mail only from the firewall, but treat this as external. (Does the MTA need to accept mail on port 25 for sending from an internal address to an external address?)
I also noted that the spammer tried some recipients within my domain (e.g.: a.a.a@mydomain.com). I was surprised to see these being moved from the tcp_intranet channel to tcp_lmtpcs. My store rejected these since there is no such user, but I would have expected the front-end MTA to handle this and not bother the store. Can anyone shed light on this?
Thanks for your help.
[1865 byte] By [
esb2000a] at [2007-11-27 11:43:42]
# 1
Hi,
> I realize that techniques for anti-spam will vary by
> site, but I'm seeking some general advice.
I can write something up on the messaging wiki which anybody can contribute to(http://msg.wikidoc.info) but as you noted, spam prevention is very much dependent on the site and any policies regarding email that you may have in place.
> Right now, all inbound mail appears first on
> tcp_intranet. I believe this is due to the firewall
> configuration, causing all message transfer to appear
> to be coming from this device's internal address.
> All external connections appeared to be internal.
This is the first thing you need to fix. Only _trusted_ internal hosts should be coming in on tcp_intranet.
> My MTA was accepting transfers from these apparent
> internal addresses, and routing to external addresses
> (open relay). I think configuring the firewall
> address as external (in mappings?) will fix this, but
> I also want to configure the MTA to be more
> restrictive if possible.
Just add something like the following to your INTERNAL_IP mappings file so that the IP of the firewall is explicitly set as NOT being internal (it should be at the top of the rules):
<firewall IP address> $N
> I think the following makes sense, and I'd appreciate
> comments on the approach, as well as pointers on how
> to configure things this way.
>
> 1. Allow mail submission only on port 587, requiring
> authentication regardless of location of user
> (internal or external). No submission on port 25.
By default port 587 requires authentication. There is no difference between mail submission and mail-delivery/relaying from the protocol level - so your statement of 'no submission on port 25' doesn't make much sense.
> 2. Accept mail on port 25 that is destined for
> internal users only.
This is the default configuration for externally sourced emails (emails that come in on tcp_local).
> Accept mail only from the
> firewall, but treat this as external.
Refer to mapping rule above.
> (Does the MTA
> need to accept mail on port 25 for sending from an
> internal address to an external address?)
Please distinguish between internal email address and internal IP address. Messaging server needs to accept mail on port 25 if you want to receive emails from any email servers.
> I also noted that the spammer tried some recipients
> within my domain (e.g.: a.a.a@mydomain.com). I was
> surprised to see these being moved from the
> tcp_intranet channel to tcp_lmtpcs. My store
> rejected these since there is no such user, but I
> would have expected the front-end MTA to handle this
> and not bother the store. Can anyone shed light on
> this?
If you run "./imsimta test -rewrite a.a.a@mydomain.com" on your MTA what do you get? The default configuration is to reject these emails so it sounds like you have changed your configuration somehow to explicitly accept these emails.
Regards,
Shane.
# 2
Shane, thanks for your thorough reply.
- The firewall is no longer internal, and messages are correctly appearing on tcp_local
- I confirmed that the MTA is only accepting mail on tcp_local destined to internal email addresses, which as you said it does by default
- Regarding port 25, I was trying to understand whether I needed the MTA to accept messages on 25 from any IP address other than that of the firewall (or perhaps an anti-spam appliance that front-ends my MTA). My users submit via 587, and all incoming mail comes from the firewall. Is it typical to restrict the MTA by the IP addresses that can transfer/submit to it? Is that even possible?
- You are right that I was confused about submission vs. transfer, but I think I understand now. My goal is to prevent users from submitting to port 25 without authentication. Can this be done, but still allow transfers from other email servers to be made on port 25 (obviously without authentication)?
- I did the rewrite test you suggested and it correctly gives the result "5.1.1 unknown or illegal alias: a.a.a@mydomain.com". But in my log I see the following (names and address changed):
22-Jul-2007 11:21:25.37 tcp_intranet tcp_lmtpcsE 2 xiop5ay@fake.net rfc822;a.a.a a.a.a@mydomain.com
22-Jul-2007 11:21:25.37 tcp_lmtpcsQ 2 xiop5ay@fake.net rfc822;a.a.a a.a.a@mydomain.com TCP active open: Failed connect() 10.00.00.100:225Error: Connection refused
The 10. address is the address of this system, the front-end MTA.
Thanks for your help.
# 3
Not necessarily best practice, but I get nice results using SpamAssassin and ClamAV (accessing both via the libraries Sun provides in the latest iMS),
and keeping this software updated.
I should also mention DNS verify & RBLs - there are reasons to avoid RBLs, but I get tremendous mileage using them (yours may vary). I retrofitted this example:
http://ims.balius.com/resources/downloads/files/mappings.txt
to my mappings file.
Chad's site above is a good resource for getting up and running (and other things but some methods like Alternate Conversion Channel might be outdated/unnecessary).
If you are interested in greylisting -which can be really controversial but is an interesting approach- (perhaps eventually thwartable by spammers), there is:
Gross:
http://code.google.com/p/gross/
which allows for a conservative greylisting approach.
You should also set up SPF in your DNS.
Anyone know about DomainKeys?
Looking forward to http://msg.wikidoc.info, thanks!
# 4
> Not necessarily best practice, but I get nice results
> using SpamAssassin and ClamAV (accessing both via the
> libraries Sun provides in the latest iMS),
> and keeping this software updated.
As an introduction to spam filtering and virus filtering the cost can't be beaten - unfortunately SpamAssassin can require a bit of work to get really good Spam matching rates whilst also providing respectable performance. If you have a small site (10,000's emails per day) not such an issue though.
> I should also mention DNS verify & RBLs - there are
> reasons to avoid RBLs, but I get tremendous mileage
> using them (yours may vary). I retrofitted this
> example:
>
> http://ims.balius.com/resources/downloads/files/mappin
> gs.txt
>
> to my mappings file.
RBL's can be very useful, making sure you choose 'reliable' ones is the hardest part of this equation. More is not necessarily better. _personally_ the SpamHaus list has proved to be very good.
I should point out that as the customer is not exposing their messaging server to the outside world, RBL's are going to be of much use in blocking email (all email will be seen to be coming from the firewall/gateway system).
> Chad's site above is a good resource for getting up
> and running (and other things but some methods like
> Alternate Conversion Channel might be
> outdated/unnecessary).
Some useful information is available on the site, but a lot has not been updated for the 6.X release of messaging server - so just bare this in mind.
> If you are interested in greylisting -which can be
> really controversial but is an interesting approach-
> (perhaps eventually thwartable by spammers), there
> is:
>
> Gross:
>
> http://code.google.com/p/gross/
>
> which allows for a conservative greylisting
> approach.
As I already noted, not necessarily useful for this customer but is a very useful mechanism none-the-less.
> You should also set up SPF in your DNS.
The use of SPF/SRS records requires that your organization have set policies in place on which systems are allowed to send emails which are coming 'from' a certain address.
http://msg.wikidoc.info/index.php/Sender_Rewriting_Scheme_%28SRS%29
> Anyone know about DomainKeys?
http://msg.wikidoc.info/index.php/DKIM_Support
> Looking forward to http://msg.wikidoc.info, thanks!
Working on it :)
Shane.
# 5
Hi,
> Shane, thanks for your thorough reply.
>
> - The firewall is no longer internal, and messages
> are correctly appearing on tcp_local
Excellent.
> - I confirmed that the MTA is only accepting mail on
> tcp_local destined to internal email addresses, which
> as you said it does by default
Correct. In case you cared the mapping rule which controls this behaviour is:
tcp_local|*|tcp_local|* $N$D30|Relaying$ not$ allowed
> - Regarding port 25, I was trying to understand
> whether I needed the MTA to accept messages on 25
> from any IP address other than that of the firewall
> (or perhaps an anti-spam appliance that front-ends my
> MTA). My users submit via 587, and all incoming mail
> comes from the firewall. Is it typical to restrict
> the MTA by the IP addresses that can transfer/submit
> to it? Is that even possible?
It is very much possible. You could achieve this by using the PORT_ACCESS mapping table to allow certain hosts coming in on port 25 and deny the rest (on port 25) e.g.
! TCP|server-address|server-port|client-address|client-port
TCP|*|25|<firewall IP>|* $Y
TCP|*|25|*|*$N500$ Please$ use$ port$ 587$ to$ send$ mail
Put the lines above *after* the INTERNAL_IP PORT_ACCESS mapping rule and define any servers that are allowed to send (firewall/anti-virus appliance) via port 25 by replacing <firewall IP> with the IP address. You can add multiples of this rule.
> - You are right that I was confused about submission
> vs. transfer, but I think I understand now. My goal
> is to prevent users from submitting to port 25
> without authentication. Can this be done, but still
> allow transfers from other email servers to be made
> on port 25 (obviously without authentication)?
The above will force your userbase to use 587, which requires authentication (as it comes in on the tcp_submit channel).
> - I did the rewrite test you suggested and it
> correctly gives the result "5.1.1 unknown or illegal
> alias: a.a.a@mydomain.com". But in my log I see the
> following (names and address changed):
>
> 22-Jul-2007 11:21:25.37 tcp_intranet tcp_lmtpcsE 2
> xiop5ay@fake.net rfc822;a.a.a a.a.a@mydomain.com
> 22-Jul-2007 11:21:25.37 tcp_lmtpcsQ 2
> xiop5ay@fake.net rfc822;a.a.a a.a.a@mydomain.com TCP
> active open: Failed connect() 10.00.00.100:225
>Error: Connection refused
> he 10. address is the address of this system, the
> front-end MTA.
Do you have a front-end/back-end server configuration?
Are you using the aliasdetourhost channel keyword (to integrate anti-virus/anti-spam or whatever?)
According to the log line above you tried to send an email via LMTP to the 'backend' but it was either not running or LMTP isn't correctly configured or you don't have a backend.
There does appear to be a configuration issue with your systems. Tracking this down can be quite involved and I may have to direct you towards logging a support call.
Regards,
Shane.
