Re: With regard to anti-spam options

[Technical Support, Stalker Labs]

Hello,

On Wed, Aug 29, 2001, 15:57:54 GMT
  David Muszynski, <[EMAIL PROTECTED]> wrote:


>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.

[skipped]

>| 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

In SIMS 1.8b8 the rbl lookup results are passed through the static blacklist, so these 
new rbl results are supported.

[skipped]

>| 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.

This is also used in SIMS to ensure that the return-path is not bogus.

>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

An empty return path is accepted in all versions. The docs here say of a return path 
with no domain part.

>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.

But if an IP from some dial-up range is used, then such a return path is useless.

>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.

But a forwarding server ("smarthost") is not necessary in the MX lis of a server.

[skipped]

>| 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

Right, this is not covered.

>... 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

But this is covered in the latest development versions: once a host hits a spamtrap it 
gets onto a temporary blacklist and will be removed from there automatically some time 
later. While on this list, that host wiull be able to send to whitelisted addresses 
only.

>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.

This won't work in many cases. Then, RFCs apper to be quite vague on the topic:

2821 updates 1123 (but not obsoletes!), and in RFC1123 we have:

      5.2.5  HELO Command: RFC-821 Section 3.5

         The sender-SMTP MUST ensure that the <domain> parameter in a
         HELO command is a valid principal host domain name for the
         client host.  As a result, the receiver-SMTP will not have to
         perform MX resolution on this name in order to validate the
         HELO parameter.

         The HELO receiver MAY verify that the HELO parameter really
         corresponds to the IP address of the sender.  However, the
         receiver MUST NOT refuse to accept a message, even if the
         sender's HELO command fails verification.

>From the newer RFC 2821 it appears that only part 3.6 applies (and 4.1.1.1 and 
>4.1.1.3 by references), but that applies to SENDER mostly, not RECIPIENT. And for the 
>latter the RFC1123 is still in effect, IMHO.

Correct me if I'm wrong.

>Do later versions of sims have rate-limiting and tar-pitting
>capabilities? Protection from dictionary attacks?

Yes.

[skipped]


Best regards,
Dmitry Akindinov

=======================================================================
When answering to letters sent to you by the tech.support staff, make
sure the original message you have received is included into your reply.

#############################################################
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]>