Actually, I've been thinking about adding queuing in two stages for 
other reasons.  Queuing just the message header would allow spamdyke to 
filter based on header lines like Subject (and log them as well).  It 
could also check the IP addresses from Received lines against DNS RBLs 
(SpamAssassin does this).  If spamdyke were to queue the entire message, 
it could do more filtering like limiting message sizes or 
stripping/blocking attachments.  Running virus and spam checkers would 
just be a nice side benefit.

I know this functionality is available elsewhere -- that's why I haven't 
added it yet.  But as I've stated before, I don't mind reimplementing 
something if I think it would be more convenient or better in spamdyke.  
If spamdyke could make it possible for an existing qmail server to use 
SpamAssassin, for example, the administrator might be willing to try 
it.  If his only other choice is to recompile and risk breaking 
everything, he won't do it.

Don't worry -- none of this is being added to the list for the next 
version.  If it happens at all, it would be several versions away.

-- Sam Clippinger

Bgs wrote:
> Spamdyke is an smtp level filtering system while virus filtering is at 
> the data level. Absolutely different by design. Spamdyke is fast because 
> it does not bother to handle data. If you add virus filtering to it, it 
> would be "just-another-virus-scanner-with-dns-checks". It would loose 
> most of what it makes valuable. to be able to virus scan you need to 
> queue the data, which takes hdd space, IO, queuing system, etc. Right 
> now data is just passed through. With tls you would loose overview 
> anyway so part of the mails cannot be filtered.
>
>
> Bye
> Bgs
>
>
> Olivier Mueller wrote:
>   
>> On Fri, 2008-05-16 at 15:39 +0200, Marcin Orlowski wrote:
>>     
>>> Sam Clippinger wrote:
>>>       
>>>> I'd love to be able to do spam and virus scanning within spamdyke, 
>>>>         
>>> But what for? There's couple of tools you can use to scan (for whatever
>>> you want) incoming mails before they go to the user mailbox and drop
>>> mails when needed. Absolutely pointless feature to be added to spamdyke
>>>       
>> Yes, but not always on SMTP-level, and IMHO it's better there since the
>> sender (if he's in the 3-4% of non-spams) will get an error message from
>> his smtp server in case of problems. Otherwise it will be "silently
>> dropped", and it's unpractical to debug issues...
>>
>> regards,
>> Olivier
>>
>>
>> _______________________________________________
>> spamdyke-users mailing list
>> spamdyke-users@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>>
>>     
> _______________________________________________
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>   
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to