Steve Cloutier wrote:
Hi !
I did a fair amount of sendmail tweaking, and it does indeed do quite a bit
(like checking for the existance of domains, etc.), but *not* the sort of
filtering I've been able to do with the external code.
Um, Yeah.. We know that. Many of us use SpamAssassin as a SMTP session
interactive scanner in their MTA (sendmail, postfix, qmail or exim).
Others run it at the MDA (ie: procmail) or MUA (ie: thunderbird) layers,
completely independent of their MTA.
The "external code" would clearly appear to apply to SA.
The filtering/blocking at the protocol level is made somewhat more difficult
by the order of operations in the SMTP protocol itself (which is a good
protocol, but it wasn't made for this level of filtering).
For instance, the content does not come across until all of the recipients
(in a list) have been processed (and approved or rejected). So, if one
wants to reject a message on the basis of some bad URL or content in the
header or body, the message has to be rejected for everyone or accepted for
everyone. Sure, I can remove the recipients who don't want the message, but
the other end doesn't get an error, and it's nice to send back an error at
the protcol level :-) Or I could deliver the message to those who don't
want that level of filtering and still reject it at the protocol level....
you get the idea :-) :-) :-) It's is the way it is, so no use kvetching
about it (the protocol) !!!! :-)
Yes, We know that too. That's why SA isn't tied to the SMTP protocol..
it's a generic filter. Data in, data out. No ties to any particular MTA,
or any particular part of the mail processing chain.You can stuff it in
anywhere you want.
Anyway, you can really do a LOT externally - things that can't be done with
sendmail alone. Of course, there's also the possiblity of integration with
other email packages which may have some sort of protocol level interface.
Yes, we know that. Our tool is external too.
The only big difference I see is your tool appears to be a quasi
nonstandard milter for sendmail, that interacts with all phases of delivery.
Personally, I use a combination of milter-greylist for filtering before
the DATA phase, and MailScanner/SpamAssassin for post delivery scanning.
Works really nicely and does about 95% of what you mention. It won't
look up text domain names in RBLs or URIBLs though, only IP based RBLs
are currently supported.
Note: milter-greylist, despite its name isn't just a greylist, it's a
complex ACL based milter that can invoke RBLs, SPF, etc. Any trigger
mechanism can be used to whitelist, greylist (with per-acl durrations)
or blacklist email. It can have ACLs both before and after the DATA
phase, although greylist isn't supported in the post data phase ACLs, as
it would be really unwise to do so from a bandwidth perspective.
