Re: [spamdyke-users] SPAM Re: Question about graylist-exception

2010-10-25 Thread Adam Bultman


Eric Shubert wrote:
> If this email is not spam, click here to submit the signatures to
> FortiGuard - AntiSpam Service.
>  Tw__&sig=e3g0toR48LxoIzFvaiVlc3l4NCx2MTNvG1NQAQ5cDhRUDUdJBEJzBxhCXAgTTgBfFgp
> TLHYxMXRoIzBsaiVSGQ0MRBZZHkQDHw1CHAtIAQgSHRpDBFYcGQlKXQELS0odEAtARRhXXFsbU1A
> BDlwOFFQNR0kEQjN0aCcxbGolZXF5YDQsdjMzdGMLeYLmmpuhIfUmyL3kY3US3w__>
> 
>   
> On 10/25/2010 10:50 AM, Adam Bultman wrote:
>> Good morning.
>>
>> I have a fairly simple question about the graylist-exception options for
>> spamdyke.conf.  I have checked the documentation, and searched the
>> mailing lists, but not found my answer.
>>
>> With other whitelist options with spamdyke, whitelisting the IP/RDNS
>> will bypass all filters.
>>
>> With graylist exceptions, it says that it will bypass the graylisting,
>> but it doesn't mention if the other filters are bypassed, or if they are
>> enforced.
>>
>> I have some domains on my spamdyke-enabled servers which go through
>> postini, and as a result I had to put the postini servers in the
>> graylist-exceptions-rdns file; but while postini doesn't have to be
>> graylisted anymore, it doesn't appear to be applying many other filters
>> (if any).  I do get some DENIED_OTHER, but I don't see any denials for
>> missing MX, or unresolvable domains, etc.  While it is possible that
>> postini is vetting those email addresses, certainly not all, because I
>> see some obvious, obvious spam running into the incoming mail queue,
>> past spamdyke.
>>
>> Is it possible that the graylist-exception is also  allowing the bypass
>> of most of the other filters as well, or am I simply ignorant of what
>> precisely the graylist exceptions are doing?  Or is it otherwise
>> impossible to run some of the other checks against the incoming mail as
>> a result of coming through postini?
>>
>> Any comments would be appreciated. In the meantime, I'll see if I can
>> update - I've have spamdyke-4.0 installed on my systems here, so the
>> graylist-exception option is available.
>>
>> Thanks,
> 
> Hey Adam. I don't know for sure about graylist exceptions, but Sam will 
> tell you for sure about that.
> 
> In the meantime, I can say that most of spamdyke's effectiveness comes 
> because it is connected to, and can thus evaluate aspects of the sending 
> server. Since postini is in between the sending server and spamdyke, 
> many of spamdyke's filters (the rDNS related ones, RBLs, and perhaps 
> others) become ineffective because spamdyke sees postini as the sending 
> server instead of the "real" sending server (which delivered to 
> postini). IOW, spamdyke is most effective only when it's on the 
> perimeter. When postini is used, spamdyke is no longer on the perimeter, 
> and is thus significantly less effective.
> 
> On a side note, I'd like to see a comparison of spamdyke to postini 
> sometime. My hunch is that spamdyke's effectiveness (paired with 
> spamassassin) rivals that of postini, but that's just a hunch. 
> Meaningful measurements of one vs the other would be difficult at best.
> 
> HTH.
> 
> -- 
> -Eric 'shubes'
> 

I just did some more research on my mail logs, and it appears that the
only denial I get with mail through postini is DENIED_OTHER, and that is
simply because the user doesn't exist on the domain. Postini in many
cases is not configured to reject nonexistent users, so the mail to
nonexistent users gets passed through to my mail servers.

It does make for a lot of useless SMTP connections - about 1,000 SMTP
connections an hour for users who don't exist, with half of those being
for a single nonexistent user on a domain!  Crazy!

Thanks for all your help, Eric.

Adam



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


Re: [spamdyke-users] SPAM Re: Question about graylist-exception

2010-10-25 Thread Adam Bultman


Eric Shubert wrote:
> If this email is not spam, click here to submit the signatures to
> FortiGuard - AntiSpam Service.
>  Tw__&sig=e3g0toR48LxoIzFvaiVlc3l4NCx2MTNvG1NQAQ5cDhRUDUdJBEJzBxhCXAgTTgBfFgp
> TLHYxMXRoIzBsaiVSGQ0MRBZZHkQDHw1CHAtIAQgSHRpDBFYcGQlKXQELS0odEAtARRhXXFsbU1A
> BDlwOFFQNR0kEQjN0aCcxbGolZXF5YDQsdjMzdGMLeYLmmpuhIfUmyL3kY3US3w__>
> 
>   
> On 10/25/2010 10:50 AM, Adam Bultman wrote:
>> Good morning.
>>
>> I have a fairly simple question about the graylist-exception options for
>> spamdyke.conf.  I have checked the documentation, and searched the
>> mailing lists, but not found my answer.
>>
>> With other whitelist options with spamdyke, whitelisting the IP/RDNS
>> will bypass all filters.
>>
>> With graylist exceptions, it says that it will bypass the graylisting,
>> but it doesn't mention if the other filters are bypassed, or if they are
>> enforced.
>>
>> I have some domains on my spamdyke-enabled servers which go through
>> postini, and as a result I had to put the postini servers in the
>> graylist-exceptions-rdns file; but while postini doesn't have to be
>> graylisted anymore, it doesn't appear to be applying many other filters
>> (if any).  I do get some DENIED_OTHER, but I don't see any denials for
>> missing MX, or unresolvable domains, etc.  While it is possible that
>> postini is vetting those email addresses, certainly not all, because I
>> see some obvious, obvious spam running into the incoming mail queue,
>> past spamdyke.
>>
>> Is it possible that the graylist-exception is also  allowing the bypass
>> of most of the other filters as well, or am I simply ignorant of what
>> precisely the graylist exceptions are doing?  Or is it otherwise
>> impossible to run some of the other checks against the incoming mail as
>> a result of coming through postini?
>>
>> Any comments would be appreciated. In the meantime, I'll see if I can
>> update - I've have spamdyke-4.0 installed on my systems here, so the
>> graylist-exception option is available.
>>
>> Thanks,
> 
> Hey Adam. I don't know for sure about graylist exceptions, but Sam will 
> tell you for sure about that.
> 
> In the meantime, I can say that most of spamdyke's effectiveness comes 
> because it is connected to, and can thus evaluate aspects of the sending 
> server. Since postini is in between the sending server and spamdyke, 
> many of spamdyke's filters (the rDNS related ones, RBLs, and perhaps 
> others) become ineffective because spamdyke sees postini as the sending 
> server instead of the "real" sending server (which delivered to 
> postini). IOW, spamdyke is most effective only when it's on the 
> perimeter. When postini is used, spamdyke is no longer on the perimeter, 
> and is thus significantly less effective.
> 
> On a side note, I'd like to see a comparison of spamdyke to postini 
> sometime. My hunch is that spamdyke's effectiveness (paired with 
> spamassassin) rivals that of postini, but that's just a hunch. 
> Meaningful measurements of one vs the other would be difficult at best.
> 
> HTH.
> 
> -- 
> -Eric 'shubes'
> 

Thanks, Eric.  I assumed that the effectiveness of spamdyke would be
significantly reduced as a result of having postini, but I wasn't sure
if spamdyke looked at the sender email address, or other options as well
to check the validity of email. At one point, I had sendmail-milter set
up on another server that did other checks inside the email, which
wasn't rendered useless by postini (And I don't expect spamdyke to do
this, so I'm not asking) - as a test case, I was going to see if setting
up an alternate port with a separate config for postini (with no
graylisting or greeting delay) would make a difference.

As for the effectiveness of postini - I know for sure that spamassassin
and spamdyke would block a ton of additional mail, more than postini
would catch.   Postini's effectiveness is reduced by a very large amount
by the rules for the domain in postini - blocking accounts that don't
exist vs. accepting and passing on, the "levels" of protection set up
for each user and for the domain as a whole, and the like.

Personally, I don't care for postini.  There's other issues I have with
postini, but I probably don't need to air them here.

Adam

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


Re: [spamdyke-users] Question about graylist-exception

2010-10-25 Thread Eric Shubert
On 10/25/2010 10:50 AM, Adam Bultman wrote:
> Good morning.
>
> I have a fairly simple question about the graylist-exception options for
> spamdyke.conf.  I have checked the documentation, and searched the
> mailing lists, but not found my answer.
>
> With other whitelist options with spamdyke, whitelisting the IP/RDNS
> will bypass all filters.
>
> With graylist exceptions, it says that it will bypass the graylisting,
> but it doesn't mention if the other filters are bypassed, or if they are
> enforced.
>
> I have some domains on my spamdyke-enabled servers which go through
> postini, and as a result I had to put the postini servers in the
> graylist-exceptions-rdns file; but while postini doesn't have to be
> graylisted anymore, it doesn't appear to be applying many other filters
> (if any).  I do get some DENIED_OTHER, but I don't see any denials for
> missing MX, or unresolvable domains, etc.  While it is possible that
> postini is vetting those email addresses, certainly not all, because I
> see some obvious, obvious spam running into the incoming mail queue,
> past spamdyke.
>
> Is it possible that the graylist-exception is also  allowing the bypass
> of most of the other filters as well, or am I simply ignorant of what
> precisely the graylist exceptions are doing?  Or is it otherwise
> impossible to run some of the other checks against the incoming mail as
> a result of coming through postini?
>
> Any comments would be appreciated. In the meantime, I'll see if I can
> update - I've have spamdyke-4.0 installed on my systems here, so the
> graylist-exception option is available.
>
> Thanks,

Hey Adam. I don't know for sure about graylist exceptions, but Sam will 
tell you for sure about that.

In the meantime, I can say that most of spamdyke's effectiveness comes 
because it is connected to, and can thus evaluate aspects of the sending 
server. Since postini is in between the sending server and spamdyke, 
many of spamdyke's filters (the rDNS related ones, RBLs, and perhaps 
others) become ineffective because spamdyke sees postini as the sending 
server instead of the "real" sending server (which delivered to 
postini). IOW, spamdyke is most effective only when it's on the 
perimeter. When postini is used, spamdyke is no longer on the perimeter, 
and is thus significantly less effective.

On a side note, I'd like to see a comparison of spamdyke to postini 
sometime. My hunch is that spamdyke's effectiveness (paired with 
spamassassin) rivals that of postini, but that's just a hunch. 
Meaningful measurements of one vs the other would be difficult at best.

HTH.

-- 
-Eric 'shubes'

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


[spamdyke-users] Question about graylist-exception

2010-10-25 Thread Adam Bultman
Good morning.

I have a fairly simple question about the graylist-exception options for
spamdyke.conf.  I have checked the documentation, and searched the
mailing lists, but not found my answer.

With other whitelist options with spamdyke, whitelisting the IP/RDNS
will bypass all filters.

With graylist exceptions, it says that it will bypass the graylisting,
but it doesn't mention if the other filters are bypassed, or if they are
enforced.

I have some domains on my spamdyke-enabled servers which go through
postini, and as a result I had to put the postini servers in the
graylist-exceptions-rdns file; but while postini doesn't have to be
graylisted anymore, it doesn't appear to be applying many other filters
(if any).  I do get some DENIED_OTHER, but I don't see any denials for
missing MX, or unresolvable domains, etc.  While it is possible that
postini is vetting those email addresses, certainly not all, because I
see some obvious, obvious spam running into the incoming mail queue,
past spamdyke.

Is it possible that the graylist-exception is also  allowing the bypass
of most of the other filters as well, or am I simply ignorant of what
precisely the graylist exceptions are doing?  Or is it otherwise
impossible to run some of the other checks against the incoming mail as
a result of coming through postini?

Any comments would be appreciated. In the meantime, I'll see if I can
update - I've have spamdyke-4.0 installed on my systems here, so the
graylist-exception option is available.



Thanks,


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


Re: [spamdyke-users] Segfault with Spamdyke 4.1.0

2010-10-25 Thread David Stiller
It's more than i thought:

[r...@plesk-mail 11:12:33:~]
# grep segf /var/log/messages | grep "Oct 25" | wc -l
6768

# dmesg  | wc -l
2655


I think it got so high as there's someone sending a newsletter.

Am 25.10.2010 um 09:38 schrieb David Stiller:

> Ok, so it's another reason. I've let spamdyke run overnight and i now i have 
> 97 Segfaults again.
> I think it's more than my config-dir, thats just a workarounf for the 
> mail-sending problem.
> So sending mail works, but stillt some spammers get disconnected. :-D Sam 
> just send me your
> IP to access my server.
> 
> -- Dave
> 
> 
> Am 25.10.2010 um 04:41 schrieb Ken S.:
> 
>> On Thu, Oct 21, 2010 at 3:36 PM, Sam Clippinger  wrote:
>>> Another option, if you don't want to fill your logs with spamdyke
>>> debugging messages, is to enable full logging ("full-log-dir").  The
>>> full logs will always contain every log message from spamdyke's most
>>> verbose setting, even if "log-level" is set to a higher value.  In other
>>> words, you can leave "log-level" set to "info" so your logs will stay
>>> the same, but the full logs will contain the "debug" messages.  If
>>> you're willing, recompiling spamdyke to include "excessive" messages
>>> would be even more helpful, as it outputs data about number of bytes
>>> sent/received.  You could then simply delete all of the full log files
>>> every day until you see a segfault appear in your logs.
>>> 
>>> Thanks for doing this, I look forward to finding out where it's crashing.
>>> 
>>> -- Sam Clipinger
>> 
>> Sam:
>> 
>> I've just switched my logging level back to info and enable the
>> 'full-log-dir' option to start dumping to a directory.  I was going to
>> recompile with the excessive option but when I looked at the output of
>> one of the files in the directory I saw data sizes logged.  Looks like
>> this:
>> 
>> 10/24/2010 22:29:26 FROM CHILD, FILTERED: 14 bytes
>> 250-STARTTLS
>> 
>> 10/24/2010 22:29:26 FROM CHILD TO REMOTE: 16 bytes
>> 250-PIPELINING
>> 
>> 10/24/2010 22:29:26 FROM CHILD TO REMOTE: 14 bytes
>> 250-8BITMIME
>> 
>> 10/24/2010 22:29:26 FROM CHILD TO REMOTE: 19 bytes
>> 250-SIZE 2500
>> 
>> 
>> Spamdyke hasn't segfaulted since 22:40 EST last Thursday:
>> 
>> Oct 21 22:40:43 mail kernel: spamdyke[2940]: segfault at
>> 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
>> 
>> I'll keep watching the logs and if it faults again I'll check the
>> files in the full-log-dir and post to this thread.
>> 
>> Thx!
>> -ken
>> 
>> 
>>> 
>>> On 10/21/10 12:55 PM, Ken S. wrote:
 I've seen a couple of these segfaults over the past year or two, but
 never really thought much about them until today when I saw three of
 them trip in a little over an hour:
 
 [r...@mail smtpd]# grep "segfault" /var/log/messages
 Oct 21 12:10:17 mail kernel: spamdyke[12243]: segfault at
 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
 Oct 21 12:48:29 mail kernel: spamdyke[24247]: segfault at
 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
 Oct 21 13:32:40 rsmail kernel: spamdyke[5630]: segfault at
 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
 [r...@mail smtpd]#
 
 Unfortunately, I don't know enough about segfaults to be able to
 decipher what the output is.
 
 I thought maybe I would look through my qmail connection log (where
 all the spamdyke stuff logs) and find out what happened at/around the
 segfault happened.  Sadly there is nothing in the logs at these times.
 
 I've just changed the "log-level" from info to debug in hopes that
 something pertinent will get logged.  If there is anything else that I
 should do to help with this, please let me know.
 
 Here is some system info:
 
 [r...@mail smtpd]# /usr/local/bin/spamdyke --version
 spamdyke 4.1.0+TLS+CONFIGTEST+DEBUG (C)2010 Sam Clippinger, samc (at)
 silence (dot) org
 ...
 [r...@mail smtpd]# uname -a
 Linux mail.yyy.zzz 2.6.9-89.0.18.EL #1 Wed Nov 25 06:04:37 EST 2009
 x86_64 x86_64 x86_64 GNU/Linux
 [r...@mail smtpd]#
 [r...@mail smtpd]# cat /etc/redhat-release
 Red Hat Enterprise Linux ES release 4 (Nahant Update 8)
 [r...@mail smtpd]#
 ... (and, yes, I'm not happy that it is a RHES4 box, but that's what I
 have to deal with right now) ...
 
 -ken
 
>>> ___
>>> spamdyke-users mailing list
>>> spamdyke-users@spamdyke.org
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>>> 
>> 
>> 
>> 
>> -- 
>> Have a nice day ... unless you've made other plans.
>> ___
>> 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/listinf

Re: [spamdyke-users] Segfault with Spamdyke 4.1.0

2010-10-25 Thread David Stiller
Ok, so it's another reason. I've let spamdyke run overnight and i now i have 97 
Segfaults again.
I think it's more than my config-dir, thats just a workarounf for the 
mail-sending problem.
So sending mail works, but stillt some spammers get disconnected. :-D Sam just 
send me your
IP to access my server.

-- Dave


Am 25.10.2010 um 04:41 schrieb Ken S.:

> On Thu, Oct 21, 2010 at 3:36 PM, Sam Clippinger  wrote:
>> Another option, if you don't want to fill your logs with spamdyke
>> debugging messages, is to enable full logging ("full-log-dir").  The
>> full logs will always contain every log message from spamdyke's most
>> verbose setting, even if "log-level" is set to a higher value.  In other
>> words, you can leave "log-level" set to "info" so your logs will stay
>> the same, but the full logs will contain the "debug" messages.  If
>> you're willing, recompiling spamdyke to include "excessive" messages
>> would be even more helpful, as it outputs data about number of bytes
>> sent/received.  You could then simply delete all of the full log files
>> every day until you see a segfault appear in your logs.
>> 
>> Thanks for doing this, I look forward to finding out where it's crashing.
>> 
>> -- Sam Clipinger
> 
> Sam:
> 
> I've just switched my logging level back to info and enable the
> 'full-log-dir' option to start dumping to a directory.  I was going to
> recompile with the excessive option but when I looked at the output of
> one of the files in the directory I saw data sizes logged.  Looks like
> this:
> 
> 10/24/2010 22:29:26 FROM CHILD, FILTERED: 14 bytes
> 250-STARTTLS
> 
> 10/24/2010 22:29:26 FROM CHILD TO REMOTE: 16 bytes
> 250-PIPELINING
> 
> 10/24/2010 22:29:26 FROM CHILD TO REMOTE: 14 bytes
> 250-8BITMIME
> 
> 10/24/2010 22:29:26 FROM CHILD TO REMOTE: 19 bytes
> 250-SIZE 2500
> 
> 
> Spamdyke hasn't segfaulted since 22:40 EST last Thursday:
> 
> Oct 21 22:40:43 mail kernel: spamdyke[2940]: segfault at
> 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
> 
> I'll keep watching the logs and if it faults again I'll check the
> files in the full-log-dir and post to this thread.
> 
> Thx!
> -ken
> 
> 
>> 
>> On 10/21/10 12:55 PM, Ken S. wrote:
>>> I've seen a couple of these segfaults over the past year or two, but
>>> never really thought much about them until today when I saw three of
>>> them trip in a little over an hour:
>>> 
>>> [r...@mail smtpd]# grep "segfault" /var/log/messages
>>> Oct 21 12:10:17 mail kernel: spamdyke[12243]: segfault at
>>> 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
>>> Oct 21 12:48:29 mail kernel: spamdyke[24247]: segfault at
>>> 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
>>> Oct 21 13:32:40 rsmail kernel: spamdyke[5630]: segfault at
>>> 007fbffbfff8 rip 003da6e73013 rsp 007fbffe75a8 error 4
>>> [r...@mail smtpd]#
>>> 
>>> Unfortunately, I don't know enough about segfaults to be able to
>>> decipher what the output is.
>>> 
>>> I thought maybe I would look through my qmail connection log (where
>>> all the spamdyke stuff logs) and find out what happened at/around the
>>> segfault happened.  Sadly there is nothing in the logs at these times.
>>> 
>>> I've just changed the "log-level" from info to debug in hopes that
>>> something pertinent will get logged.  If there is anything else that I
>>> should do to help with this, please let me know.
>>> 
>>> Here is some system info:
>>> 
>>> [r...@mail smtpd]# /usr/local/bin/spamdyke --version
>>> spamdyke 4.1.0+TLS+CONFIGTEST+DEBUG (C)2010 Sam Clippinger, samc (at)
>>> silence (dot) org
>>> ...
>>> [r...@mail smtpd]# uname -a
>>> Linux mail.yyy.zzz 2.6.9-89.0.18.EL #1 Wed Nov 25 06:04:37 EST 2009
>>> x86_64 x86_64 x86_64 GNU/Linux
>>> [r...@mail smtpd]#
>>> [r...@mail smtpd]# cat /etc/redhat-release
>>> Red Hat Enterprise Linux ES release 4 (Nahant Update 8)
>>> [r...@mail smtpd]#
>>> ... (and, yes, I'm not happy that it is a RHES4 box, but that's what I
>>> have to deal with right now) ...
>>> 
>>> -ken
>>> 
>> ___
>> spamdyke-users mailing list
>> spamdyke-users@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>> 
> 
> 
> 
> -- 
> Have a nice day ... unless you've made other plans.
> ___
> 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