I posted a link to the anti-spam documentation page for SIMS on another
mail-server list that I belong to in the hopes of learning the strengths and
weaknesses of SIMS as well as MailTraq (both products that I use in
different environments). The main response that I got was quite interesting
but brings up some questions that I'm not able to answer competently. I'm
hoping that some of the gurus here will lend a hand by answering or
clarifying anything that they can to this list which I'll then forward back
to the other list. Here's the post in it's entirety, please comment on
sections that you can, I'll cat the posts at my end. I mentioned in the
original post to the MailTraq list that this documentation was still showing
v1.7, so if you can say that something specific has improved for 1.8x I'd
like to hear about that too.
TIA
______________________
David Muszynski in <[EMAIL PROTECTED]>:
> Jim Hill imposed structure on a stream of electrons yielding:
>
> > What sort of blocklist dns lookup config does sims require? Does
> > it permit custom reject strings to be used?
>
> http://www.stalker.com/sims/AntiSpam.html
Thanks for the reference. Taking things in order on that page.
The retry interval on the SMTP Service Settings dialog is too
short (15 mins) if it's the default. From rfc2821 (4.5.4.1
Sending Strategy) ...
| The sender MUST delay retrying a particular destination after one
| attempt has failed. In general, the retry interval SHOULD be at
| least 30 minutes; however, more sophisticated and variable strategies
| will be beneficial when the SMTP client can determine the reason for
| non-delivery.
Again assuming defaults, 200 retries at 4 per hour is ~2 days
which is fine but that looks like the bounce point and there
appears to be no separately defined delivery delay warning.
~300 simultaneous inbound smtp connects is a hell of a load for
what I thought originally was simply an end-user mta. Obviously a
serious piece of kit.
| Blacklisting Offenders
I like the (firewall) blacklist syntax. Mailtraq badly needs
something like that. For example, the following range is all
apnic assigned to China ...
61.128.0.0 -- 61.191.255.255
... and sims can handle it neatly in one entry as shown above.
Entering that ip address range using Mailtraq's firewall syntax
takes an awful lot of individual entries ...
61.128.*.*
61.129.*.*
61.13?.*.*
61.14?.*.*
61.15?.*.*
61.16?.*.*
61.17?.*.*
61.18?.*.*
61.190.*.*
61.191.*.*
| Using DNS-based Blacklisting
|
| The SMTP module then tries to "resolve" this name into an
| IP address. If this operation succeeds and the retrieved
| IP address is 127.0.0.2, then the aaa.bbb.ccc.ddd address
| is considered to be blacklisted.
Presumably, your later version offers more flexible handling of
the returned ip address. With rbl+ lookups, for example ...
127.1.0.1 RBL
127.1.0.2 DUL
127.1.0.3 DUL and RBL
127.1.0.4 RSS
127.1.0.5 RSS and RBL
127.1.0.6 RSS and DUL
127.1.0.7 RSS and DUL and RBL
| Note: this option results in an additional DNS operation
| and thus it can cause delays in processing of incoming
| connections.
That and false positive management are the two major problems
with dns blacklists from my point of view.
| Relay Restrictions and Mobile Users
|
| the POP module of the Server remembers all IP addresses used
| to make successful connections to a user mailbox. For 30 seconds
| those IP addresses [...] can send mail via your Server
The chances of another user taking over a dynamically assigned ip
address within 30 seconds and attempting unauthorised relay
through the same smtp server must be astronomically slim. Hardly
worth imposing the added hassle of having to re-authenticate for
every send, I would have thought.
| Verifying Return-Path Addresses
|
| If your SMTP module can accept incoming TCP connections,
| your server can be used by spammers as a mail relay engine:
| they can distribute their messages all over the world using your
| server. To protect your site from spammers, the SMTP module
| can verify the Return-Path address (specified with the Mail From
| SMTP command) of incoming messages.
The documentor must have had an off-day there. Verifying the
reverse path has nothing to do with relay control. It's simply a
means of ensuring that the receiving server can discharge its
full responsibility for the incoming message -- either deliver to
the forward path or bounce to the reverse path.
Hopefully, the first refusal clause "the Return-Path domain name
is an empty string (no domain specified)" has been modified in
later versions to accept valid nul reverse paths. Ditto the final
refusal clause "the Return-Path domain name is specified as an IP
address, and that address is not included into the Client Hosts
list" because it's completely spurious afaics. Dotted quads are
legitimate domain replacements throughout rfc2821.
I must confess that I wouldn't like to impose reverse path
restrictions except when the forward path couldn't be verified by
the receiving server, ie when it's acting as an authorised mx
relay for a remote domain.
| When the Return-Path domain cannot be verified because the Domain
| Name Server that keeps its records is not available, the module
| refuses to accept the message [and] returns a "temporary" error
| code to the sending system.
I think that's a very good idea but, again, I'd only want to
implement it if the forward path wasn't locally verifiable.
| Blacklist-Routing and "White Holes"
Although I don't like the use of the percent hack in this
context, the underlying concept is something which is badly
needed in Mailtraq, imo. The ability to whitelist "abuse" and
"postmaster" with global effect is an essential asset in an mta.
| Spam Traps
This implementation seems a little lame by comparison with the
rest of the anti-spam facilities. It wouldn't cause any problems
here but it wouldn't have much effect either. The underlying
assumption that spam runs involve multiple recipients per connect
doesn't hold true here. For example, as written, it appears to
cover only this ...
mail from:<blah>
rcpt to:<user@domain>
rcpt to:<spamtrap@domain>
... and it's not clear whether it covers this ...
helo blah
mail from:<blah>
rcpt to:<user@domain>
data
rset
mail from:<blah>
rcpt to:<spamtrap@domain>
data
quit
... and doesn't seem to cater for this at all ...
helo blah
mail from:<blah>
rcpt to:<spamtrap@domain>
data
quit
...
helo blah
mail from:<blah>
rcpt to:<user@domain>
data
quit
An awful lot more could be gained from this feature than appears
to be case according to that documentation.
Related topics not mentioned on that reference:
There appears to be no means of verifying that the helo parameter
is a valid domain (syntax and dns), nor that the ip address of
the connecting client reverses correctly to the helo parameter.
Those are surprising omissions in its otherwise comprehensive
anti-spam facilities.
Do later versions of sims have rate-limiting and tar-pitting
capabilities? Protection from dictionary attacks?
It's clear from an overall standpoint that sims has much more
sophisticated mail handling facilities than Mailtraq although
they seem more aimed at the solo techie user, imo, than the
average company user. Still, they point to the direction in which
Mailtraq should be evolving, imo.
I also enjoyed reading that documentation. It's rare to find mta
capabilities outlined so succinctly and clearly. I hope that
others here find the time to read and comment on it as well.
______________________
Thanks,
David Muszynski
Art Director
Technology Marketing Corp.
http://www.tmcmktg.com
321.728.1611
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
