Chris Hoogendyk wrote:
>
>
> Henrik K wrote:
>> On Fri, Mar 07, 2008 at 10:07:16PM -0800, Steve Cloutier wrote:
>>
>>> Hi !
>>>
>>> Call me -- whatever :-) I took a look at SpamAssassin a while back, and
>>> (at
>>> least at the time), it seemed to scan the mailbox file after the
>>> message(s)
>>> were received. The program (again, at the time) was written in Perl.
>>>
>>> This whole process seemed somewhat inefficient, and also allowed the
>>> spammer
>>> to believe their messages were getting through.
>>>
>>
>> SpamAssassin is only a filter. There are many ways to run it at SMTP
>> level.
>>
>> Also there are plenty of software that does the features you listed. And
>> a
>> proper MTA can do most of the features you mentioned even by itself. Not
>> to
>> start a flame war, but it seems it's always the Sendmail people who need
>> to
>> come up with fancy custom milters etc. ;)
>>
>
> Well, actually, we use sendmail, and, as I read the original post, I was
> thinking myself, umm, a lot of these are things you can do with sendmail
> without any additional code. So, maybe it's just people who see they can
> do a milter but don't take the time to learn all the depth of what they
> can already do.
>
> I'm not the local expert on sendmail, but I did the original install and
> I do the maintenance. My boss has dug in and done some of the tweaks.
> Several years ago he attended a usenix seminar by Eric Allman and added
> quite a lot to what he knew about sendmail. The latest O'Reilly book on
> sendmail provides lots of depth to plumb.
>
>
>>> If anyone wants to test this, you're welcome to do so. Contacat me with
>>> what you're running for
>>> a platform, and I'll see if I can generate an executable for you.
>>>
>>
>> I'm sure everyone is dying to get "some executable" running in their
>> systems.
>> How about sources? :)
>>
>
>
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.
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) !!!! :-)
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.
Regards,
Steve
Anyway,
--
View this message in context:
http://www.nabble.com/Yet-another-spam-blocker--tp15911630p15918095.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
