Re: [spamdyke-users] yet another wishlist... :-)

[Bgs]

IMHO doing an in memory header cache might be a good idea. Given its 
size, there is no need to create files, but add some additional simple 
filtering options.

Going toward any file operations other than the graylist system is not a 
good idea for spamdyke methinks :)


Regards
Bgs


Sam Clippinger wrote:
> 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
> 
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Michael Colvin]

Makes perfect sense, and I share you paranoia with touching qmail on a
production machine...  I'm doing all my playing currently on a test box, so
that I don't have my phones light up.  :-)
 

Michael J. Colvin
NorCal Internet Services
www.norcalisp.com

 



 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Sam 
> Clippinger
> Sent: Friday, May 16, 2008 2:01 PM
> To: spamdyke users
> Subject: Re: [spamdyke-users] yet another wishlist... :-)
> 
> Well, to answer your question, spamdyke is aimed at... me.  
> And mail administrators like me, I suppose. :)
> 
> Some history: The first time I installed qmail, I used the 
> qmail handbook by Dave Sill.  All of my previous Unix mail 
> experience was with Sendmail, so I didn't understand anything 
> about qmail's design or configuration.  I didn't even know 
> what the term "toaster" meant (I'm still not 100% certain 
> about that word...).  I just followed the book's 
> instructions, which said (IIRC) to use netqmail 1.03, 
> vpopmail, qmailadmin, vqadmin and ezmlm.  I prefer working at 
> the command line and I'm (obviously) a programmer, so 
> patching and compiling didn't bother me.  I was just 
> surprised at the necessity -- I hadn't manually installed a 
> major system component like a mail daemon since I switched to 
> RedHat 4 from Slackware in 199x.  I wouldn't have bothered 
> with qmail at all, but I wanted to host multiple domains on 
> the same box and I was sick of Sendmail's lousy virtual 
> domain support.
> 
> Anyway, _after_ qmail was installed and in production, I 
> learned about some additional patches to add things like 
> virus scanning, SpamAssassin, etc.  However, when I tried to 
> apply and install them, everything broke.  No inbound or 
> outbound email, angry users, long nights, etc.  I finally 
> managed to restore the system to its former state and swore 
> never to touch a working qmail installation again.  That's 
> still my motto, BTW, despite everything I've learned about 
> qmail since that incident.  It's just easier (and safer) to 
> build a new server and swap it into position.
> 
> Now here I am, running a mail server I'm scared to update.  
> Is there a new version of vpopmail available?  I don't know.  
> I'm not even sure what version I'm using.  Have some of the 
> patches been updated to fix security holes?  How would I 
> possibly find out?  I can't remember where I got most of them 
> (or even which ones I used).  I don't care anyway -- I'm not 
> going to install them, because I'm hosting Real Email for 
> Real Customers and my time is too precious to pick fights 
> with qmail that I'll probably lose.  So welcome back to the 
> Bad Old Days of Linux system administration.  This is why 
> "rpm" and "apt-get" were created but DJB's bullheaded 
> obstinacy renders those tools useless.
> 
> That's why I say spamdyke is targeted at me.  I want 
> filtering and logging but I'm not willing to recompile qmail 
> to get those things.  I want a package that is small and 
> self-contained, so I can upgrade it (or use 
> rpm/yum/up2date/apt-get) without fear of losing my job.  When 
> I first created spamdyke, I wanted it to (eventually) replace 
> every qmail patch, because it meant fewer patches would have 
> to be applied to new qmail installations.  Nowadays, in the 
> presence of maintained and preconfigured qmail distributions 
> like QmailToaster, that need is somewhat lessened and I can 
> concentrate on features that aren't available through patches 
> (or are difficult to use or are broken).  At the same time, I 
> don't want to forget about the mail administrators running 8 
> year old qmail installations that they're scared to touch. :)
> 
> -- Sam Clippinger
> 
> Michael Colvin wrote:
> > This will sound strange after all the "Suggesting" I've 
> done recently but...
> > :-)
> >
> > I think Sam's idea/concept for SpamDyke, if I understand it 
> correctly, 
> > is ideal.  Make something that is easy to install, adds 
> functionality 
> > to a basic Qmail install without a lot of patching.  I 
> think having a 
> > completely STOCK qmail install, adding something like SpamDyke that 
> > can do all the filtering in front of qmail, would make the complete 
> > package better.  Face it, a lot of people don't use qmail 
> because they 
> > are scared of all the patches, and the fact that it isn't 
> > "Maintained", which, is actually kind of funny..They 
> con

Re: [spamdyke-users] yet another wishlist... :-)

[Sam Clippinger]

a stock qmail install, this is also true.
>
> So, who is SpamDyke *REALLY* geared towards?  Not a retorical question, I'm
> actually curious.  I've found it very helpful and very effective.  As I dig
> beyond "Qmailrocks" into other variations of installing qmail, I'm finding
> most of SpamDykes functions, or at least the ones I'm using, implemented
> directly in Qmail via patches.  Perhaps avoiding the patches is the benefit.
> How often do we really upgrade the core functionality of qmail...The stuff
> that would need to be recompiled should we upgrade something?  Qmail's core?
> Not in years.  Vpopmail?  Yea, occassionally, if you want to, or if a
> bug/exploit is discovered..(When was the last time tha happened?)
> Qmail-queue?  Probably more than the others, but still seldom, and not a big
> deal to do...
>
> Anyway...  Enough rambling.  I need to figure out how I'm going to implement
> all these cool toys in qmail.  :-) 
>
> Michael J. Colvin
> NorCal Internet Services
> www.norcalisp.com
>
>  
>
>
>
>  
>
>   
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Sam 
>> Clippinger
>> Sent: Friday, May 16, 2008 9:29 AM
>> To: spamdyke users
>> Subject: Re: [spamdyke-users] yet another wishlist... :-)
>>
>> 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
>> 
>
> ___
> 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

Re: [spamdyke-users] yet another wishlist... :-)

[Faris Raouf]

It is still a big perl script :-)

We've not had any issues with memory/cpu with it but I expect our servers
aren't as busy as others.
 
Faris.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:spamdyke-users-
> [EMAIL PROTECTED] On Behalf Of Olivier Mueller
> Sent: 16 May 2008 16:18
> To: spamdyke users
> Subject: Re: [spamdyke-users] yet another wishlist... :-)
> 
> On Fri, 2008-05-16 at 14:31 +0100, Faris Raouf wrote:
> > Forgive me if I'm missing something here, but qmail-scanner already
> does
> > spamassassin and AV checking, and can be configured to reject (as
> opposed to
> > drop) any emails that fall outside of admin/user set parameters.
> 
> I used q-s in the past, but had to drop it because of memory/cpu-use
> issues... As far as I remember it was an huge perl script started on
> every incoming mail: is it still the case?   (better would be something
> like spamd + spamc).
> 
> But I guess it's still a fine solution for low-trafic servers :)
> 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

Re: [spamdyke-users] yet another wishlist... :-)

[Michael Colvin]

This will sound strange after all the "Suggesting" I've done recently but...
:-)

I think Sam's idea/concept for SpamDyke, if I understand it correctly, is
ideal.  Make something that is easy to install, adds functionality to a
basic Qmail install without a lot of patching.  I think having a completely
STOCK qmail install, adding something like SpamDyke that can do all the
filtering in front of qmail, would make the complete package better.  Face
it, a lot of people don't use qmail because they are scared of all the
patches, and the fact that it isn't "Maintained", which, is actually kind of
funny..They consider postfix "Maintained" because it gets occassional
updates...Yet, even with things like SpamDyke and the various patches/smtp
additions, the don't consider Qmail "Updated", because the auther isn't
bundling the changes himself...

Anyway...  Most people tha run Qmail are likely running, netqmail, qmail
with jms's patchs, or qmailrocks, or a stock qmail.  Those with jms's
patches and netqmail have most of what's built into SpamDyke, by
modifying/changing the smtp to rblsmtp, as I understand it.  So, instead of
an outside application doing that scanning and handing it off to an smtp
daemon to process, the smtp daemon does the processing...Not sure which is
better.

Qmailrocks has it's downsides, so in that case, SpamDyke definetely adds
some much needed additions, and makes them easy to implement.  Obviously,
with a stock qmail install, this is also true.

So, who is SpamDyke *REALLY* geared towards?  Not a retorical question, I'm
actually curious.  I've found it very helpful and very effective.  As I dig
beyond "Qmailrocks" into other variations of installing qmail, I'm finding
most of SpamDykes functions, or at least the ones I'm using, implemented
directly in Qmail via patches.  Perhaps avoiding the patches is the benefit.
How often do we really upgrade the core functionality of qmail...The stuff
that would need to be recompiled should we upgrade something?  Qmail's core?
Not in years.  Vpopmail?  Yea, occassionally, if you want to, or if a
bug/exploit is discovered..(When was the last time tha happened?)
Qmail-queue?  Probably more than the others, but still seldom, and not a big
deal to do...

Anyway...  Enough rambling.  I need to figure out how I'm going to implement
all these cool toys in qmail.  :-) 

Michael J. Colvin
NorCal Internet Services
www.norcalisp.com

 



 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Sam 
> Clippinger
> Sent: Friday, May 16, 2008 9:29 AM
> To: spamdyke users
> Subject: Re: [spamdyke-users] yet another wishlist... :-)
> 
> 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

___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Olivier Mueller]

On Fri, 2008-05-16 at 17:56 +0200, Marcin Orlowski wrote:
> What SMTP-level you talk about? You need to get all the data prior checks
> we talk about. And this makes *huge* difference.

SMTP-Level = during the SMTP Session, before the mail is accepted in the
local qmail queue. 

Once the mail is in the local queue, you can still run checks on the
mail (virus, spam, etc.). But if you then drop the mail, the sender will
not know that unless you send an error message by mail, which is not so
recommended as nearly all spams are sent with faked return-path/from
headers  

regards,
Olivier


___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Sam Clippinger]

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

Re: [spamdyke-users] yet another wishlist... :-)

[Marcin Orlowski]

Olivier Mueller wrote:

> I used q-s in the past, but had to drop it because of memory/cpu-use
> issues... As far as I remember it was an huge perl script started on
> every incoming mail: is it still the case?   (better would be something
> like spamd + spamc). 

You can always substitute qmail-local by your own code (even bash script works
like w/o no harm) which would scan the mail (i.e. by calling any external tool 
you
wish), drop or bounce it if needed needed (virus?) or just hand over to
original qmail-local to continue delivery. Works like a harm for years here and
keeps perl away.

Regards,
-- 
"Daddy, what "Formatting drive C:" means?"...

Marcinhttp://wfmh.org.pl/carlos/
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Marcin Orlowski]

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

What SMTP-level you talk about? You need to get all the data prior checks
we talk about. And this makes *huge* difference.

Regards,
-- 
"Daddy, what "Formatting drive C:" means?"...

Marcinhttp://wfmh.org.pl/carlos/
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Eric Shubert]

Well said. It wouldn't be spamDYKE at that point. ;)

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


-- 
-Eric 'shubes'
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Bgs]

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

Re: [spamdyke-users] yet another wishlist... :-)

[Olivier Mueller]

On Fri, 2008-05-16 at 14:31 +0100, Faris Raouf wrote:
> Forgive me if I'm missing something here, but qmail-scanner already does
> spamassassin and AV checking, and can be configured to reject (as opposed to
> drop) any emails that fall outside of admin/user set parameters.

I used q-s in the past, but had to drop it because of memory/cpu-use
issues... As far as I remember it was an huge perl script started on
every incoming mail: is it still the case?   (better would be something
like spamd + spamc). 

But I guess it's still a fine solution for low-trafic servers :)
regards,
Olivier


___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Olivier Mueller]

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

Re: [spamdyke-users] yet another wishlist... :-)

[Andras Korn]

On Fri, May 16, 2008 at 03:39:15PM +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.

FWIW, I use amavisd-new to integrate qmail with SA and clamav. Works pretty
well.

Andras

-- 
 Andras Korn 
  QOTD:
  Time passes... Does that mean it's my turn again?!
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Marcin Orlowski]

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.


Regards,
-- 
"Daddy, what "Formatting drive C:" means?"...

Marcinhttp://wfmh.org.pl/carlos/
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Faris Raouf]

Forgive me if I'm missing something here, but qmail-scanner already does
spamassassin and AV checking, and can be configured to reject (as opposed to
drop) any emails that fall outside of admin/user set parameters.

Because qmail-scanner is so easy to install (especially if you have Plesk
under RedHat/Centos) I'm not sure if there's a point in having the same
features in Spamdyke? (qmail-scanner and spamdyke work perfectly together
with no changes needed to make it happen).

This is not to say that the original poster's idea is a bad one, or that
having the facility in spamdyke rather than in yet another qmail
wrapper-thing isn't a good one. I'm just thinking that maybe it isn't all
that necessary.

Faris.


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:spamdyke-users-
> [EMAIL PROTECTED] On Behalf Of Sam Clippinger
> Sent: 16 May 2008 04:25
> To: spamdyke users
> Subject: Re: [spamdyke-users] yet another wishlist... :-)
> 
> I'd love to be able to do spam and virus scanning within spamdyke,
> before the connection is complete.  That would require spamdyke to
> start
> SpamAssassin and/or ClamAV (or another AV) and capture their output.
> It
> shouldn't be too hard, since both of those programs are designed to be
> run this way.
> 
> The biggest change required in spamdyke would be buffering the incoming
> message.  Currently spamdyke doesn't do this, it only passes the
> traffic
> between the network and qmail.  In order to scan the message, it would
> have to save it (probably to a file) so it could first pass it to the
> scanners, then pass it to qmail afterwards.
> 
> Thanks for the suggestion!  I'll add it to my TODO list for a future
> version.
> 


___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Re: [spamdyke-users] yet another wishlist... :-)

[Sam Clippinger]

I'd love to be able to do spam and virus scanning within spamdyke, 
before the connection is complete.  That would require spamdyke to start 
SpamAssassin and/or ClamAV (or another AV) and capture their output.  It 
shouldn't be too hard, since both of those programs are designed to be 
run this way.

The biggest change required in spamdyke would be buffering the incoming 
message.  Currently spamdyke doesn't do this, it only passes the traffic 
between the network and qmail.  In order to scan the message, it would 
have to save it (probably to a file) so it could first pass it to the 
scanners, then pass it to qmail afterwards.

Thanks for the suggestion!  I'll add it to my TODO list for a future 
version.

Olivier Mueller wrote:
> Hello,
>
> I'm not (yet) spamdyke user, but this may change soon: the project looks
> very promising, congratulations :)  Finally something not 100% based on
> qmail-patches... 
>
> At the moment (as you maybe noticed on the qmail ML), I'm thinking about
> redesigning my mail systems, and this is what I'd like to do. Maybe this
> will give you some ideas or suggest some feedback:
>
>
>
> ... SMTP Session Starting ...
>
> 1) Check IP address against 2-3 RBL (blacklists) and 1-2 
>whitelists (of swiss/german/french/etc. ISP mail 
>server ip's)   
>-> transmit the result to a script which will decide
>   (based on logs created in 2), 4) and 5))
>   if it wants to reject the connexion or not: 
>   my goal would be to be able to tune this based   
>   on recipient domain/mail address for legal reasons...
>-> return a 5xx error or continue 
>
>
> 2) VRFY check (in my case: with cvm-vmailmgr, via
>http://untroubled.org/cvm/  because most my users are
>vmailmgrd-based)
>-> 5xx error if not valid, and log ip  (to add to a local
>   blacklist)  or continue
>
>
> 3) Greylist if requested/allowed by the domain owner, 
>and if not in the IP whitelist
>
>
> ... Receive Mailheader/Body ... 
>
>
> 4) Virus scan (clamdscan/fsav/etc.)
>-> exit with Virus Name in the 5xx error message
>   if a virus is found   (+ log ip), else continue
>
>
> 5) Spam scan   (with parameters like "required hits"
>taken from the database, to let the user decide
>what to accept/reject, and for example store the
>spam to a temporary quarantine for further analysis) 
>-> error 5xx if flagged as spam   (+ log ip)
>
>
> ... Deliver mail ...
>
>
>
> At the moment, I only have rblcheck (but server-wide, not based on
> domain), recipient check and virus check (via qmail-qfilter) on SMTP
> level.  Antispam scan occurs after via .qmail-* files.  But it seems it
> is not appropriate anymore, now I think everything must be scanned (and
> rejected) at directly at SMTP level.
>
> Feedback welcome :-)   In the mean time, I'll activate some features of
> spamdyke on a test system to see if it is going to be able to help.
>
> 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