Re: [spamdyke-users] make fails on FBSD
It's related because it explains the meaning of segmentation fault. However, it also says that there are only two possibilities -- either there's a bug in the program or a hardware problem. If this error is consistent and repeatable at all hours of the day or night, it's not a hardware issue. That leaves a software bug in gcc (because gcc is crashing, not spamdyke). Something about the structure, layout or size of spamdyke's code tickles this particular bug but without more information there's no way to understand exactly what's happening. Unfortunately, gcc is one of the most complex pieces of software ever created and debugging it is not a trivial task (I would rate it beyond monumental -- simply recompiling gcc is not for the timid). Because I can't fix gcc, all I can recommend is to contact the gcc authors or to change versions of gcc, if possible. Sorry. -- Sam Clippinger K. Shantanu wrote: * Sam Clippinger [EMAIL PROTECTED] [081003 08:11]: This looks like a problem with gcc. Version 3.4.6 is the most recent version before 4.x, so it might be worthwhile to submit a bug report to [...] While reading FBSD FAQ, I chanced upon this. Does it seem related? http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#SIGNAL11 Thanks. Shantanu ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] make fails on FBSD
One solution: gcc4 from ports. If your fbsd installation is too old (4.x or 5.x) update it. d. 2008/10/3 Sam Clippinger [EMAIL PROTECTED]: It's related because it explains the meaning of segmentation fault. However, it also says that there are only two possibilities -- either there's a bug in the program or a hardware problem. If this error is consistent and repeatable at all hours of the day or night, it's not a hardware issue. That leaves a software bug in gcc (because gcc is crashing, not spamdyke). Something about the structure, layout or size of spamdyke's code tickles this particular bug but without more information there's no way to understand exactly what's happening. Unfortunately, gcc is one of the most complex pieces of software ever created and debugging it is not a trivial task (I would rate it beyond monumental -- simply recompiling gcc is not for the timid). Because I can't fix gcc, all I can recommend is to contact the gcc authors or to change versions of gcc, if possible. Sorry. -- Sam Clippinger K. Shantanu wrote: * Sam Clippinger [EMAIL PROTECTED] [081003 08:11]: This looks like a problem with gcc. Version 3.4.6 is the most recent version before 4.x, so it might be worthwhile to submit a bug report to [...] While reading FBSD FAQ, I chanced upon this. Does it seem related? http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#SIGNAL11 Thanks. Shantanu ___ 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] DKIM etc.
Felix Buenemann wrote: Hi, I agree with Arthur and Bgs in that SPF is a smarter thing to check, because it can be done without checking headers and currently has a much wider disribution base. IMHO the only way to properly reject DKIM failed mail is at the end of the DATA command, which is exactly how eg. simscan rejects virii or spam mail. So IMHO DKIM verification is something to do for a queue-handler not a frot end smtp handler, that is geared for high performance. (This is based on the assumtion, that spamdyke deals with 99% of the scam with very little cpu time, thus reducing server load and leaving more in depth checks to those mails that slip through spamdyke's already tight web.) -- Felix Good thinking, Felix. Some things just don't belong in spamdyke as is. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] whitelisting a handful of domains while graylisting others
Folks, is it possible to simply allow immediate delivery to a handful of domains, while graylisting the rest to the standard defined graylisting policy? Seems some folks would rather just get instant gratification and spam, rather than have a minimal delay with the extra protection graylisting offers. I'm not able to pinpoint it in the docs. I noticed graylist-exception-rdns-dir yet this seems to apply to remote servers, and we're interested into the local domains we receive email for. Thanks. -- Erald Troja ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] whitelisting a handful of domains while graylisting others
Erald Troja wrote: Folks, is it possible to simply allow immediate delivery to a handful of domains, while graylisting the rest to the standard defined graylisting policy? Seems some folks would rather just get instant gratification and spam, rather than have a minimal delay with the extra protection graylisting offers. I'm not able to pinpoint it in the docs. I noticed graylist-exception-rdns-dir yet this seems to apply to remote servers, and we're interested into the local domains we receive email for. Thanks. You need spamdyke =4.0 for this. If I understand correctly, use the greylist-level=always in your config, and then be sure that there's no domain directory contained in the greylist-dir directory. See http://spamdyke.org/documentation/README.html#GRAYLISTS -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] whitelisting a handful of domains while graylisting others
Eric's suggestion will work fine, although you don't need version 4.0 to use it -- the previous versions could be configured that way as well. Another solution is to use spamdyke version 4.0 and create a configuration directory (using the config-dir option) for each of the recipient domains that want immediate delivery. In your global config file, enable graylisting as normal. In the configuration directory files for the specific domains, disable graylisting. The advantage of this technique is that you can still use graylist-level=always-create-dir in the global config file to automatically create domain directories as needed. Either solution will accomplish the same thing. -- Sam Clippinger Eric Shubert wrote: Erald Troja wrote: Folks, is it possible to simply allow immediate delivery to a handful of domains, while graylisting the rest to the standard defined graylisting policy? Seems some folks would rather just get instant gratification and spam, rather than have a minimal delay with the extra protection graylisting offers. I'm not able to pinpoint it in the docs. I noticed graylist-exception-rdns-dir yet this seems to apply to remote servers, and we're interested into the local domains we receive email for. Thanks. You need spamdyke =4.0 for this. If I understand correctly, use the greylist-level=always in your config, and then be sure that there's no domain directory contained in the greylist-dir directory. See http://spamdyke.org/documentation/README.html#GRAYLISTS ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] make fails on FBSD
You can always put a newer version of gcc in a special directory and do a custom build with it this would allow both versions to co-exist. Matt The owner of the server is bit pessimist about upgrading gcc for he fears, it might break things especially since the server is a live one. What do you think, is it safe? The server simply hosts websites and email. Shantanu ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
