Re: [spamdyke-users] Blacklist all, but allow 1 or 2 IPS?
I think I see what you're trying to do. I'd set up the mail scanners to use smtproutes for the domains they're processing, and use authentication on port 587 for relaying to the plesk host. Then to block incoming mail from other hosts, remove these domains from the rcpthosts file. That will make plesk accept email for those domains only from authenticated connections. I think that'll do what you're looking to achieve. P.S. QMT is getting less tightly coupled as changes are made, so using it in specialized roles will get easier all the time. It's pretty simple now to pick and choose what functionality you wish to keep with your QMT by simply turning off services you don't use. It'll continue to get easier to do though, with less bloat. The latest packages are a big move toward removing bloat, as the build environment is no longer needed. This is also a boon to security. Thanks. -- -Eric 'shubes' On 09/30/2014 04:53 PM, Faris Raouf wrote: Eric, your advice is always appreciated - never hesitate to give it! I didn't explain the situation fully for brevity - the mailscanners do have spamdyke. They do all the email spam blocking, scanning etc, but only for particular domains. And since they do so, I don't want the Plesk box to do any scanning at all on email that comes from them, but I do want it to totally reject any mail that comes from any other IP (e.g. spammers sending to www A record and ignoring MX record), hence the need to whitelisting the scanner's IPs and blacklisting all other IPs. But I only want to do this on the Plesk box for those domains that the mailscanners handle - there are other domains on the Plesk box that have no external scanner and do need the full assistance of spamdyke, spamassassin and clamd running on the Plesk box. I've done some testing and it works pretty well so far. The x-y wildcard works with an ip-blacklist-entry line. QMailToaster is almost what I want as a mailscanner, but does more than I need really in that it designed to act as a full mailserver rather than just as an AV/AS node. I am going to investigate it more, as I think it is really interesting. I've previously looked at Mailscanner with the Baruva GUI but it took me many hours of attempting to install all sorts of python this and python that and totally failing to get them all to install or compile even when following a step-by-step (many, many pages!) instruction list, so I gave up. -Original Message- From: spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users- boun...@spamdyke.org] On Behalf Of Eric Shubert Sent: 30 September 2014 02:31 To: spamdyke-users@spamdyke.org Subject: Re: [spamdyke-users] Blacklist all, but allow 1 or 2 IPS? I don't want to tell you what to do, but spamdyke is pretty much useless in that configuration. In order to be effective, spamdyke needs to be on the perimeter, connecting directly to the sending servers. You'll need to put spamdyke in front of the mailscanner nodes for it to be at all effective. Have you thought of putting the mailscanner nodes behind spamdyke? That'd be fairly easy to do, but you'd need 2 qmail hosts to accomplish it, one with spamdyke in front, and another behind handling delivery. For that matter, you could put a postfix server (or whatever else you like, like exchange perhaps) behind the mailscanner nodes. That would be an effective, and I would guess fairly common configuration. Personally, I would simply use QMailToaster and forget about the mailscanner nodes. ;) -- -Eric 'shubes' On 09/29/2014 03:59 AM, Faris Raouf wrote: Can someone point me in the right direction please? I'm setting up a couple of av/anti-spam mailscanner nodes. These nodes will process email for two particular domains, then send the filtered messages on to a more general purpose hosting/email system that's running spamdyke and deals with email for many other domains. I want to stop this hosting system from accepting mail from any IPs other than the mailscanner nodes, but just for these two particular domains. I know how to create a domain-specific config file for spamdyke. What I'm not terribly sure of is how to blacklist all and allow only the IPs I want. Can I do it by ip-blacklisting 1-254. and ip-whitelisting the IPs I want? e.g, in the domain-specific config file: #blacklist all ip-blacklist-entry=1-254 And in my global spamdyke.conf I'd have the mailscanner nodes whitelisted, so I don't have to do it in lots of files if they ever change IPs): #whitelist IPs of mailscanners ip-whitelist-entry=1.1.1.1 ip-whitelist-entry=2.2.2.2 Or does the 1-254 format only work when I'm using an ip blacklist FILE? Any help/suggestions would be appreciated! (background - I don't want to run clamd/Spamassassin on emails coming in from the IPs of the mailscanner nodes, but have no way to switch scanning off only for email that comes in via a particular IP. My only option is, therefore, to switch off av/sa completely
Re: [spamdyke-users] Another case for SPF checking
On 07/31/2014 05:59 PM, Eric Shubert wrote: When spamdyke eventually implements SPF checking, I'd like to see an option whereas if the SPF record is enforcing and the check passes, then all other filters (such as rDNS etc) will pass. Personally, I'm willing to give the benefit of the doubt to any domain which has a valid enforcing SPF record. I could see where some admins might not wish to be so lenient, so making this optional seems appropriate. On second thought, this isn't necessarily a good idea. I just came across some spam that not only had a valid SPF record (although it wasn't enforcing, it had ~all), it also had valid DKIM. So I should amend this suggestion, that if SPF is enforcing and the check passes, then *some* filters will pass, namely those that the mailer has control of. RBL filters (which the mailer doesn't control) should still be honored in any case. Perhaps this makes the SPF filter too complicated. I wouldn't want this to delay having SPF implemented in spamdyke. As always, thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Another case for SPF checking
Sometimes it's the big mailers who can't seem to get their servers configured right. I recently had a problem receiving statement notices from US Bank, who uses postdirect.com to deliver said notices. As it were, postdirect.com appears to have re-provisioned some sending servers to IPs that no longer have resolvable rDNS names, so spamdyke dutifully rejects them. I think it's interesting that the folks at postdirect.com (of all people) did manage to have a correct (and enforcing) SPF record for the IP/server in question, but failed to set up rDNS appropriately. When spamdyke eventually implements SPF checking, I'd like to see an option whereas if the SPF record is enforcing and the check passes, then all other filters (such as rDNS etc) will pass. Personally, I'm willing to give the benefit of the doubt to any domain which has a valid enforcing SPF record. I could see where some admins might not wish to be so lenient, so making this optional seems appropriate. Any thoughts about this? Thanks. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] TLS Timeouts from Amazon
On 07/04/2014 10:54 AM, Joe @ 3ZZZ wrote: Greetings, Yesterday a client reported that he stopped receiving alerts from Amazon seller central as of July 1st. In maillog, found many entries such as: Jul 4 06:16:28 *hostname* spamdyke[27351]: TIMEOUT from: rte+ne-null-de34ca1aqnutb9y9...@sellernotifications.amazon.com to: cli...@clientdomain.com origin_ip: 54.240.13.37 origin_rdns: a13-37.smtp-out.amazonses.com auth: (unknown) encryption: TLS reason: TIMEOUT Found this post in the archive which seems to be related: https://www.mail-archive.com/spamdyke-users@spamdyke.org/msg03994.html and I'm going to try recompiling today for the suggested excessive output. In the meanwhile, wondering if anyone else is seeing this? (Amazon is a rather large sender and it seems more than this one client on my server is being affected now) Currently on spamdyke v 4.3.1 and wondering if upgrading to 5.0 might resolve this? Going to try today but would appreciate any input in advance, if available. thank you, Joe I've seen some of these too, now that you mention it (and I went looking for some). I rebuilt an excessive spamdyke, captured a few full logs, and sent them directly to Sam (they're a little big to post here). I can't tell much regarding the error from the log, and I won't speculate other than to say that the problem appears to be at the very end of the smtp session. I expect we'll hear from Sam soon about the prognosis. Thanks. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Uptick in spam
On 06/11/2014 01:51 PM, Angus McIntyre wrote: On Jun 11, 2014, at 9:43 AM, Gary Gendel g...@genashor.com wrote: In the last month, I've seen a large increase in spam that breezes through spamdyke and spamassassin. These are html only emails mainly for jobs from the big web companies (Google, Facebook, etc.). The html is biased with bayes poisoning keywords. These aren't _actually_ job offers from Google and Facebook. If you followed the links (which I don't necessarily, advise, because the spammers 'tag' the links so they can see who looked at the message) you'd find that they redirect to syndicated marketing links promoting scammy work-at-home make-money-fast schemes. I think the only connection with Google or Facebook is that these fake jobs are somehow on the Internet. The links point to a page with a number of unrelated links via a tracker. I assume they are trying to get click-through cash. Yep. Anyone else see this kind of problem? If so, what are you doing about it? I wrote about the difficulty of blocking these in another thread on 'spamdyke-users' with the subject Fwd; Search for High Speed Internet options near you (someone else posted a sample of a similar spam). Basically, because the senders change domain names, IP addresses, 'From' lines, 'Subject' lines, and even URL formats continuously, and because the messages contain hashbuster text, they're extremely difficult to block reliably. They're pretty much the state-of-the-art when it comes to randomizing every possible element that could be used as the basis for filtering. I don't know if this helps, but I'm seeing that some come from sites without a compliant dns setup. For example: 162.210.198.19 - hosted-by.EqServers.com hosted-by.EqServers.com - 65.60.49.189 Would spamdyke's rDNS tests help here? In my experience, these particular spammers usually have their DNS properly set up -- they're posting from rented servers hosted by a variety of hosting companies, rather than botnet PCs -- so they don't usually get turned away by Spamdyke's rDNS checks. I think Bayesians may work on them, despite the presence of hashbuster text: most of them that I see trigger SpamAssassin's BAYES_99 rule, and in my tests with CRM-114 I can usually get CRM-114 to say Oh yeah, it's one of those. However, BAYES_99 defaults to a score of 3.5, which may not be enough on its own to take the message over the threshold to be tagged as spam. Now that you're starting to see these, you're going to get more and more. They have ramped up their sending volume enormously over time, and are sending more and more in an attempt to brute-force their way through. Angus Good points. Personally, I've adjusted my SA scoring to weigh bayes heaver. FWIW, this is what I use: score BAYES_00 0 0 -2.612 -2.899 score BAYES_05 0 0 -1.110 -1.110 score BAYES_20 0 0 -0.740 -0.740 score BAYES_40 0 0 -0.185 -0.185 score BAYES_50 0 0 0.001 0.001 score BAYES_60 0 0 1.5 1.5 score BAYES_80 0 0 3.0 3.0 score BAYES_95 0 0 4.0 4.0 score BAYES_99 0 0 5.1 5.1 I also use: required_score 3.7 Personally, I haven't noticed this problem. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Fwd: Search for High Speed Internet options near you
I haven't seen this sort of thing in quite some time (thankfully). Have you sent them through sa-learn so bayes can detect them? -- -Eric 'shubes' On 06/03/2014 09:53 AM, David wrote: Thats where I was headed with this one.. UGH! How annoying. We need a honeypot approach for these guys and then tarpit them into a blackhole. I will post a resolve on this once a I try a few things. thanks Dave On 06/03/2014 11:19 AM, Angus McIntyre wrote: On Jun 3, 2014, at 11:25 AM, David dmilho...@wletc.com wrote: How in the world do I stop these annoying emails. according to the headers they change the From: Subject: and the domains and ips change as well. It looks like an affiliate spammer. They typically rent a block of IP addresses from one or more hosting providers, then start pumping out spam with syndicated marketing links in it, and get paid when suckers click on the links. I don't recognize this particular one's style, but the bad news is that they tend to be really hard to filter. As you've found out, they constantly change domain names (they probably use domain-kiting to ensure that they never have to pay for names), they constantly change IPs (so-called snowshoe spamming, aided by compliant ISPs), they use hashbuster text in their messages to get past or poison statistical filters, and they constantly change their subjects, from lines, and in some cases even their URL formats. Unfortunately, Spamdyke isn't a lot of help against these guys. They are actually delivering from real mailservers (as opposed to botnet PCs), so graylisting won't help. They generally have their DNS set up correctly, so rDNS checks won't reject them. They change names and IPs so fast that RBLs struggle to keep up. They are among the hardest spammers to block. I suggest that you collect samples of the spam that you're receiving and then analyze them. It's possible that you may be able to identify a small number of IP blocks used by the spammer and block those, although they change IPs and hosting services continually to avoid that. A more productive approach may be to try to identify patterns in the URLs that they use and write a SpamAssassin rule to recognize them. The URL in the sample you sent is very long and complex, which means that you have quite a good chance of writing a regex that would recognize their spams but wouldn't generate false positives on legitimate emails. Angus ___ 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] Questions about qrv
On 05/30/2014 04:13 PM, Les Fenison wrote: However, I have still had issues where spammers send with matching to/from addresses Evidently plesk doesn't handle this. And of course, this should ONLY happen for unauthenticated users as some people send to themselves to test. I've found that provided all users authenticate properly and they only submit via your server (and they should if they don't), blacklisting your local domains works well to block this type of spam. Authenticated users can still send to themselves since they authenticate, and messages that illegitimately masquerade as your domain(s) are blocked. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Port number in log messages (and other log musings)
I just noticed that the port number associated with a session doesn't appear to be included in log messages. This will become significant for QMT when spamdyke is added to the submission port, as QMT will be using a centralized logging facility (ELK stack - ElasticSearch, Logstash and Kibana) in the near future. I suppose this could also be achieved with a tag= configuration parameter which could be included in the log messages. This feature might be useful for folks with multiple configurations. Any chance of getting this bit of data included in the log messages? I see there's already a high priority for adding other message data. Also on the subject of logging, I see there's already a request to make log messages configurable. Along these lines, it would be useful to me to have an option to have log messages formatted as JSON (http://en.wikipedia.org/wiki/Json), so they can be processed directly by Logstash without additional parsing. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
Marc ( Sam),
Would you please elaborate a little on this? I'm trying to straighten
things up on QMail-Toaster and could use a little help. I'm far from an
openssl expert, but I'm learning. ;)
The qmail TLS patch that's presently in place (Frederik Vermeulen -
qmail-tls 20060104 http://inoa.net/qmail-tls/) is a little outdated. It
has provisions for rsa512.pem along with dh512.pem and dh1024.pem files.
I see that rsa key exchange is now disabled by default, so that code is
dead.
I'm wondering though about dh512.pem vs dh1024.pem files. These are
generated by the openssl dhparam command for the respective key lengths.
From the patch code, I see that a key length parameter is given to the
callback function, which controls which pem file is used. Here's the
callback function from the patch:
+DH *tmp_dh_cb(SSL *ssl, int export, int keylen)
+{
+ if (!export) keylen = 1024;
+ if (keylen == 512) {
+FILE *in = fopen(control/dh512.pem, r);
+if (in) {
+ DH *dh = PEM_read_DHparams(in, NULL, NULL, NULL);
+ fclose(in);
+ if (dh) return dh;
+}
+ }
+ if (keylen == 1024) {
+FILE *in = fopen(control/dh1024.pem, r);
+if (in) {
+ DH *dh = PEM_read_DHparams(in, NULL, NULL, NULL);
+ fclose(in);
+ if (dh) return dh;
+}
+ }
+ return DH_generate_parameters(keylen, DH_GENERATOR_2, NULL, NULL);
+}
I'm at a loss determining where this keylen comes from. I'm not finding
where it's set or determined.
I'm also wondering, should 2048 and 4096 key lengths also be included?
They are mentioned in the man page
(http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html) Notes
section, but not in the code examples found there.
How are the multiple key lengths implemented (distinguished) in the
tls-dhparams-file option of the spamdyke configuration?
Thanks for your help with this. I'm learning a lot.
P.S. Sam, the documentation refers to openssl dhparams. Should be
openssl dhparam (no S in dhparam).
P.P.S. Sam, the documentation says the default list of ciphers is
usually fine. What *is* the default list? Same as what the openssl
ciphers command returns (iow, all of them, in no particular order)?
Thanks again.
--
-Eric 'shubes'
On 02/05/2014 06:34 AM, Marc Gregel wrote:
Just for the records:
With Version 5.0.0 and the new option tls-dhparams-file everything
works great, TLS uses the strong cipher suites now!
Thank you :-)
2013-09-10 Marc Gregel m...@gregel.net
mailto:m...@gregel.net:
Looking forward to the Update :-)
2013/9/10 Sam Clippinger
s...@silence.org
mailto:s...@silence.org
I think you're exactly right -- I'll need to add another TLS
option to spamdyke to accept the DH parameters and pass them to
OpenSSL with the callback. I'll have to figure out how to test
it as well...
Thanks for finding that link, I don't think I would have even
looked at a function with tmp in its name!
-- Sam Clippinger
On Sep 9, 2013, at 3:34 AM, Marc Gregel wrote:
Hi Sam,
is it possible that the problem is because of missing dh keys?
I think (!) spamdyke don't use or call something like this here:
http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html -
read the 'notes' part
so cipher with EDHE:DE won't work.
My server/openssl is fine because the orginal qmail-tls works
with cipher EDHE_DH! So the problem is the tls handling of
spamdyke?!
2013/9/8 Sam Clippinger
s...@silence.org
mailto:s...@silence.org
Hmmm... I think you may be beyond the edge of my
expertise, but I'll certainly try to help if I can.
spamdyke uses the OpenSSL library to handle SSL and TLS,
so anything that works with OpenSSL on the command line
should work with spamdyke as well. The option
tls-cipher-list serves the same function as the
-cipher option to openssl. spamdyke just takes the
text it's given and passes it to
the SSL_CTX_set_cipher_list() function in the OpenSSL
library before the connection is established. The ciphers
you give should be ones listed when you run openssl
ciphers from the command line, I'm not sure how it
handles abbreviations.
It's possible the problem is actually within openssl's
SMTP client. If it's not starting the SMTP connection and
asking for TLS correctly, the client could be sending
encrypted text while the server is still in plaintext mode
or vice-versa. That would yield some strange error
messages on both sides.
I think I would suggest configuring spamdyke on port 465
with tls-level set to smtps and the tls-cipher-list
option set to your
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
I posted that just a *little* too early. Here the answer to my previous questions: http://openssl.6102.n7.nabble.com/Size-of-ephemeral-DH-keys-td15181.html Sam, the post scripts still apply. On 03/28/2014 11:47 AM, Eric Shubert wrote: P.S. Sam, the documentation refers to openssl dhparams. Should be openssl dhparam (no S in dhparam). P.P.S. Sam, the documentation says the default list of ciphers is usually fine. What*is* the default list? Same as what the openssl ciphers command returns (iow, all of them, in no particular order)? Thanks. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
On 02/05/2014 06:34 AM, Marc Gregel wrote: Just for the records: With Version 5.0.0 and the new option tls-dhparams-file everything works great, TLS uses the strong cipher suites now! Thank you :-) Marc, What key length are you using in your dhparams file? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Spamdyke message header
With spamdyke handling TLS and authentication, this visibility in the message headers disappears. What's the status of having spamdyke insert a header into the message indicating such things (and whatever else might be pertinent)? Or is that already in 5.0? Thanks. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] No TLS with openssl elliptic curve cipher suites / pfs perfect forward secrecy
That should no doubt work, but it doesn't appear to be ideal for current use. While I think BC is referring to signed certs, what we're referring to here is the key exchange portion of the ciphers used with SSL. My (somewhat limited) understanding is that they use related technology, but their application here is different. Sam's implementation of tls-dhparams-file appears appropriate for this day and age. It's up to the admin to generate this file with whatever key length is deemed appropriate for the application. The former various key lengths are a relic left over from when export rules were restrictive according to key lengths. My only concern with using 2048 bit dh params is something I saw warning that some servers might not be able to handle keys that big. I doubt that's any longer the case. I just changed my dh1024.pem file to contain 2048 key length dh params. We'll see what happens. Thanks. -- -Eric 'shubes' On 03/28/2014 01:12 PM, Marc Gregel wrote: Eric, at the moment I use the same file the normal qmail installation use. spamdyke.conf: tls-dhparams-file=/var/qmail/control/dh1024.pem 2014-03-28 20:08 GMT+01:00 Eric Shubert e...@shubes.net mailto:e...@shubes.net: On 02/05/2014 06:34 AM, Marc Gregel wrote: Just for the records: With Version 5.0.0 and the new option tls-dhparams-file everything works great, TLS uses the strong cipher suites now! Thank you :-) Marc, What key length are you using in your dhparams file? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto: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] timeout results in duplicates
On 02/08/2014 02:40 PM, Sam Clippinger wrote: I'm a little unclear here -- what scanning are you doing and when does it take place? I'm not crystal clear either about exactly how everything's happening. Simscan is invoking clamav and spamassassin. Simscan is implemented via QMAILQUEUE=/var/qmail/bin/simscan. How can spamdyke tell the difference between a delay caused by something on your server versus a delay from the remote sender? I've no idea. I'm guessing that simscan isn't given control until the message is completely received. It's at that point, when the message has been completely received but not yet queued, that I think the idle timeout should be disabled. The problem appears to be that when when spamdyke does idle timeout, the qmail-queue process can still successfully deliver a message (when it's past the point described above). spamdyke should only initiate a timeout when it can (still) keep a message from being delivered. Here's a sample from the log which might make things a little clearer: 02-07 14:15:14 tcpserver: status: 1/100 02-07 14:15:14 tcpserver: pid 19001 from 70.58.xxx169 02-07 14:15:14 tcpserver: ok 19001 tacs-mail.datamatters.us:192.168.73.7:25 :70.58.xxx.169::44872 02-07 14:15:23 CHKUSER accepted sender: from x...@x.com:: remote ..com:unknown:70.58.xxx.169 rcpt : sender accepted 02-07 14:15:23 CHKUSER accepted any rcpt: from x...@.com:: remote ..com:unknown:70.58.xxx.169 rcpt x...@.com : accepted any recipient for this domain 02-07 14:15:23 policy_check: remote x...@.com - local x...@.com (UNAUTHENTICATED SENDER) 02-07 14:15:23 policy_check: policy allows transmission 02-07 14:16:25 spamdyke[19001]: TIMEOUT from: x...@.com to: x...@.com origin_ip: 70.58.xxx.169 origin_rdns: .com auth: (unknown) encryption: TLS reason: TIMEOUT 02-07 14:17:58 simscan:[19002]:CLEAN (5.50/12.00):154.6404s:***SPAM*** Fwd_ 70.58.xxx.169:x...@.com:x...@.com 02-07 14:17:58 tcpserver: end 19001 status 0 Usually, the simscan message comes before spamdyke. BL is that the message is delivered, and the sender is notified of a failure, causing duplicates in the inbox. Thanks Sam. Gotta run. -- Sam Clippinger On Feb 7, 2014, at 4:37 PM, Eric Shubert e...@shubes.net mailto:e...@shubes.net wrote: With spamdyke 4.3.1, I've come across an email which takes an inordinate amount of time to scan, for whatever reason. I had idle-timeout=60, so spamdyke would timeout the session, and a minute or so later the scan completes, and the message is delivered. This causes duplicates though, as the sender isn't aware of the successful delivery. I've bumped up the idle-timeout to 180, which I expect will remedy the situation. I wonder, though, if this setting could or should be suspended during the time which spamdyke is waiting for delivery to happen. Perhaps there should be 2 settings - one for the incoming side and one for the delivery side? I like keeping this setting on the low side to keep senders from tying up incoming processes, yet the setting doesn't seem to make any sense when waiting for scanning/delivery, especially when spamdyke can't cancel that part of things. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto: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 -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] timeout results in duplicates
With spamdyke 4.3.1, I've come across an email which takes an inordinate amount of time to scan, for whatever reason. I had idle-timeout=60, so spamdyke would timeout the session, and a minute or so later the scan completes, and the message is delivered. This causes duplicates though, as the sender isn't aware of the successful delivery. I've bumped up the idle-timeout to 180, which I expect will remedy the situation. I wonder, though, if this setting could or should be suspended during the time which spamdyke is waiting for delivery to happen. Perhaps there should be 2 settings - one for the incoming side and one for the delivery side? I like keeping this setting on the low side to keep senders from tying up incoming processes, yet the setting doesn't seem to make any sense when waiting for scanning/delivery, especially when spamdyke can't cancel that part of things. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] RDNS WhiteList Not Working
On 01/31/2014 03:32 PM, Denny Jones wrote: I'm using SpamDyke 4.3.1 I have whitelisted gfoxconsulting.com in whitelist_rdns (I simply added gfoxconsulting.com to that file) I have the whitelist_rdns file indicated correctly in the spamdyke.conf file: rdns-whitelist-file=/etc/spamdyke/whitelist_rdns ...but I still, this domain (gfoxconsulting.com) being rejected: Jan 31 09:58:04 michael spamdyke[13182]: DENIED_RDNS_MISSING from: l...@gfoxconsulting.com to: al...@texasalliance.org origin_ip: 208.123.81.4 origin_rdns: (unknown) auth: (unknown) encryption: TLS reason: (empty) However on the very next log line I get: Jan 31 10:08:35 michael spamdyke[15441]: ALLOWED from: l...@gfoxconsulting.com to: al...@texasalliance.org origin_ip: 208.123.81.4 origin_rdns: exch01.redglue.com auth: (unknown) encryption: TLS reason: 250_ok_1391184515_qp_15469 What is going on here? Thanks, Denny ___ I think you're perhaps missing how rdns whitelisting works. rDNS is a name which is associated with an ip address. In the first instance, the rDNS record is missing, so there's no name to match to (origin_rdns = (unknown)). There's no way to use rdns whitelisting to let this one through. You'd need to whitelist something else, like either the IP address (good choice) or the sender domain (not recommended). It's possible (even likely) that someone at redglue.com discovered that there was no rdns for this IP, and it was fixed sometime before 10:08 (the missing message could have resulted from a cached lookup). It's also possible that there's an obscure bug in spamdyke. This is unlikely, but it's been known to happen occasionally with odd DNS configurations. I'd call this an odd rDNS configuration: $ host 208.123.81.4 4.81.123.208.in-addr.arpa is an alias for 4.255-0.81.123.208.in-addr.arpa. 4.255-0.81.123.208.in-addr.arpa domain name pointer exch01.redglue.com. $ There's a cname record pointing to the ptr record. Usually the rdns name is a ptr record, not a cname (ttbomk). I'd wait to see if the problem recurs. If it doesn't, then the problem was likely with the sender's rDNS which is now fixed. If it reoccurs, then it's probably a bug. Sam will know the bottom line here. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] New version: spamdyke 5.0.0
On 01/28/2014 08:42 AM, Sam Clippinger wrote: Just when you thought it was safe to go back in the water... spamdyke version 5.0.0 is now available! Get it here: http://www.spamdyke.org/ This version is a major update that adds 12 new options, renames 3 options and removes 5 options. The meaning of whitelisted is changed to allow whitelisted connections to bypass spamdyke's filters but not to automatically relay (unless allowed for some other reason). DNS searches for valid sender domains will now prioritize MX records before A records. Full recipient validation is now available. Sender addresses can be rejected if they don't match the username given during authentication (or if the domain doesn't match). Lots of bug fixes too! Because of all the changes to spamdyke's options, version 5.0.0 is not backwards compatible with previous versions. Be sure to read the documentation before upgrading! -- Sam Clippinger ___ Terrific, Sam. I'll get this built in the QMT testing repo as soon as the existing 4.3.1 version is promoted to 'current', which I expect will be in the next few weeks. I'm looking forward to testing it out. Many thanks (as always). -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Account verification question
In the forthcoming spamdyke release, will spamdyke be able to verify the account of only vpopmail, or will it work with other/any email software (via smtp)? I don't mean to push, but have a spamdyke installation fronting a kerio mail system where this would be desirable, and would like to know if spamdyke will be able to handle this or if I need to come up with something else. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
There's a units parameter along with the size. My man page doesn't indicate a default value. I'd try: -size 0c On 12/17/2013 03:36 AM, emailitis.com wrote: Hi Gary, I love your easy to execute scripts, thank you. I would like to delete any files that are 0 bytes in size AND are over 3 days old. I tried to be clever: find /var/qmail/graylist/beadonbrook.com/. -type f -size 0 -mtime +3 –print (missed out the –delete until I had checked, luckily as it happens). but that lists all those that are greater than 3 days and ignores the “-size 0” in there. Can you help with how best to do that? Kind Regards, Christoph *From:*spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users-boun...@spamdyke.org] *On Behalf Of *Gary Gendel *Sent:* 23 November 2013 02:09 *To:* spamdyke users *Subject:* Re: [spamdyke-users] 0byte graylist entries My graylists do get constantly pruned but others seem to have old ones remaining. Then again, my graylist-max-secs is set to 1296000 (one day) which is probably shorter than most. On 11/22/13, 8:15 PM, BC wrote: Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub:https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto: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 -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Outbound spam prevention
I've drawn up specs for a throttle for qmail-remote. Haven't had time to write the patch for it yet, but hope to do so in the next few months. -- -Eric 'shubes' On 12/10/2013 10:21 AM, ron wrote: Such a solution would be nice. I can empathize with you as it happened to me about 8 months ago and it took me several hours to figure how to stop it, although they weren't being created as fast as yours. Scanned all PC's with Malware Bytes and didn't find any process that could be definitely identified as the culprit, but removed anything suspect. Ron On 12/10/2013 9:35 AM, Les Fenison wrote: I had one of my email users accounts compromised this morning and have been thinking of what could have prevented hundreds of thousands of spams from going out all within a 2 minute window. Is there any way possible to limit the number of emails that a single authenticated user can send within a specified period of time? Fortunately I was awake and an alarm alerted me to an enormous mail queue and I was able to quickly change the compromised password. But not until over 400,000 messages got queued. I dumped the queue immediately but time will tell how many blacklists my IP ends up on because of this. -- Les Fenison www.DeltaTechnicalServices.com https://www.deltatechnicalservices.com l...@deltatechnicalservices.com (503) 610-8747 ___ 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] ssl libraries (apparently) not found on Plesk install
I've installed spamdyke on a Plesk host. It's working for the most part, but when I run the test, it indicates that spamdyke was built without TLS support, which is true: spamdyke 4.3.1+CONFIGTEST+DEBUG (C)2012 Sam Clippinger, samc (at) silence (dot) org The openssl libraries appear to be installed: openssl-1.0.0-27.el6_4.2.x86_64 How can I get spamdyke to build with TLS? (Or, what am I missing?) Thanks Sam. P.S. No, this is not *my* Plesk server. ;) -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] ssl libraries (apparently) not found on Plesk install
On 11/27/2013 02:07 PM, Eric Shubert wrote: I've installed spamdyke on a Plesk host. It's working for the most part, but when I run the test, it indicates that spamdyke was built without TLS support, which is true: spamdyke 4.3.1+CONFIGTEST+DEBUG (C)2012 Sam Clippinger, samc (at) silence (dot) org The openssl libraries appear to be installed: openssl-1.0.0-27.el6_4.2.x86_64 How can I get spamdyke to build with TLS? (Or, what am I missing?) Thanks Sam. P.S. No, this is not *my* Plesk server. ;) Never mind. Didn't have openssl-devel installed. Doh! -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
I don't see a real problem here. I think the -mtime parameter on directories causes empty directories to stick around longer than need be though. The script is a bit nicer in my mind. It processes each domain individually, and optionally gives statistics regarding what it did, without listing every single file/directory it deleted. Note, the stats take an additional find to count the total number of graylist entries, so it runs a little longer than when it's run silently. Having said that, I've come to the conclusion that graylisting isn't worth it to me. I disabled graylisting several months ago, and haven't really noticed any less effectiveness. Measuring the effectiveness of graylisting properly is very difficult, and it's a pain for users (myself included) at times. With all of the other filters spamdyke provides, I don't think the cost of graylisting is worth the benefit. Of course, YMMV. -- -Eric 'shubes' On 11/22/2013 06:15 PM, BC wrote: Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub:https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ 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] 0byte graylist entries
On 11/23/2013 09:05 AM, BC wrote: On 11/23/2013 8:55 AM, Eric Shubert wrote: Having said that, I've come to the conclusion that graylisting isn't worth it to me. I disabled graylisting several months ago, and haven't really noticed any less effectiveness. Measuring the effectiveness of graylisting properly is very difficult, and it's a pain for users (myself included) at times. With all of the other filters spamdyke provides, I don't think the cost of graylisting is worth the benefit. Of course, YMMV. Curious you bring that up. In perusing the logs, it (very subjectively) looks like r_dns lookups are blocking 95% of the spam, RBL is getting about 4% and graylisting is only being invoked about 1% of the time. That feels about right to me, again very subjectively. The tough part about measuring graylisting is that of the 1% of the times it's invoked how many were spam? It's pretty hard to tell. I don't know of anyone who's measured this accurately. I suppose the pruning script could be modified (quite easily in fact) to give a count of how many empty files it removed. I think that would be an accurate measure. I'm a little surprised I didn't think of that the last time I edited the script. I'll see about making that change when I put the script in the spamdyke rpm (and on github). But what is the cost of graylisting? Graylisting delays a legit email by X amount of minutes. Is that the pain of which you are talking? Yes. I realize that the impact of the delay is infrequent, but when it happens, it's really annoying, and it impacts productivity. In my case, it usually happens when an email confirmation or notification of some sort is required to do something. This is the absolute worst time for there to be a delay, as it interrupts that process. As a user, I was very happy to have graylisting turned off. As an email administrator, I am tired of trying to explain how delaying delivery of email is necessary to help reduce spam. Graylisting is simply not a good solution because of the negative impact on the users. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
On 11/23/2013 09:39 AM, Eric Shubert wrote: I suppose the pruning script could be modified (quite easily in fact) to give a count of how many empty files it removed. I think that would be an accurate measure. I'm a little surprised I didn't think of that the last time I edited the script. I'll see about making that change when I put the script in the spamdyke rpm (and on github). The modified script is available here: https://github.com/QMailToaster/pkgs/blob/master/spamdyke/sd-prune-graylist I'd be interested to see some results if someone would care to post their counts. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub: https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Blocking Authenticated Users Taken Over By Virus
Hey Sam. As I see it, this problem is on the outbound side of things, so I wouldn't look for spamdyke to be able to much of anything that's very effective. As I mentioned on the QMT list, the best solution I've seen to this problem is what gmane.org does, namely throttles the outbound messages per account. I'm hoping to patch qmail-remote some day to provide a similar throttle. qmail-remote would wait N seconds between sends for any particular user/domain/host. While spam would back up in the QMT queue, I think this would be a good solution. The administrator could then take appropriate measures. I've made some notes on how this might work. gmane.org is open source too, so I intend to have a look at their code to see how they're doing it. Any ideas re how you might implement this easily? TIA. -- -Eric 'shubes' On 11/18/2013 03:25 PM, Sam Clippinger wrote: This is definitely a common problem with no simple solution. As it stands right now, spamdyke could help solve this but not alone... probably the simplest solution would be to create a wrapper for the authentication command used by spamdyke and qmail. If that command were to keep a log of successful authentications, it could enforce a rate limit of X messages per Y minutes and deny authentication attempts after the rate is exceeded. There's no reason it shouldn't be able to send you an alert at the same time. spamdyke and qmail both look for the return codes on the external authentication scripts. Your wrapper would just need to run the real authentication command, check its return code to see if it succeeded, then check the rate limit. If the rate limit is exceeded, return a failure code. Otherwise, return the real return code. spamdyke would handle the rest by rejecting the remaining messages. It would be cool to add this kind of feature to spamdyke in the future but there are some other changes that would need to take place first (most importantly spamdyke would need to run as a daemon), so it's probably quite a ways off. -- Sam Clippinger On Nov 15, 2013, at 11:28 AM, Denny Jones wrote: Hello all, I have this intermittent issue... I host many clients and every once in a while one of my users will get a virus and start spewing out spam emails. I came in this morning and found one had sent over 3000 in just an hour. I have scripts in place that alert me about this so I'm able to catch it but I want to catch it sooner - perhaps auto-stop it. NOTE: These are authenticated users who's email programs have been hi-jacked and are sending with valid logins. My setup is QmailToaster Plus, SpamDyke, SpamAssassin, Fail2Ban, ClamV - all with the latest versions. I am curious about how other admins handle this situation? Surely I'm not the only one being bitten by this. FYI - I ran this on the Qmail list and it was suggested that I might run this by the SpamDyke list as well. Thanks in advance, Denny ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto: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] So close and yet so far...
On 10/21/2013 10:48 AM, Sam Clippinger wrote: I have some good news and some bad news... The good news: spamdyke version 5.0.0 is done, tested and ready. The biggest new feature is recipient validation -- spamdyke uses the qmail's configuration files and duplicates qmail's logic to determine if an address is valid, so there's no need to maintain a separate file of valid addresses. The testing has taken forever to finish, but it's finally done! The bad news: the recipient validation feature doesn't work, at least not for me. Imagine my chagrin when I tried to install it on my own server and every incoming message was rejected. I ran all of my unit tests as root, but in the real world spamdyke runs as non-root. qmail is very modular, which means the configuration files are owned by different user(s) than the mail folders, which means no one non-root user has access to all of the files needed to validate an address. I tried changing the permissions on folders to allow access, but qmail will only queue messages and won't deliver them when the permissions are too loose. Running spamdyke as root would work, but I'm just not comfortable recommending that as a solution. So, as soon as I finish wiping the egg off my face, I have another solution in mind that should be pretty easy to implement. But first I need a little help. I'd like to know how the file ownership and permissions are setup on different qmail servers. My own server was installed using the instructions from lifewithqmail.org http://lifewithqmail.org and only root can see all the necessary files for recipient validation. However, that may not be true for other installations. So if a few of you are willing, could you send me an email to let me know: How your server was installed (QmailToaster, Plesk, lifewithqmail.org http://lifewithqmail.org, qmailrocks.org http://qmailrocks.org, etc)? In your /var/qmail/users/assign file, what UID and GID are given in fields 3 4 and what username and group name do those map to? The 5th field in /var/qmail/users/assign gives a folder path. What user and group owns those folders and what permissions are set on those folders (and the subfolders)? There should be a system user named alias on your server. What permissions are set on that user's home folder and the .qmail files found there? Thanks so much (in advance) for your help! I was really really looking forward to posting the new version today and I'm very disappointed I can't do that. Needless to say, I'll be working on fixing this issue as quickly as I can so I can roll out the new version ASAP. -- Sam Clippinger Interesting timing, Sam. I just finished coding a spamdyke rpm package (the first?) for spamdyke last night. It should be available on repoforge in the near future. I'm in the process of upgrading all of the QMailToaster packages for CentOS6, and spamdyke will be officially integrated with that release. FWIW, QMT will also have yum support (hopefully via repoforge), and dovecot on the back end of things. I'm presently in the midst of changing qmail-toaster so that it'll build as a non-root user (I recently completed doing this to vpopmail as well). BL, I'm already up to my waist in qmail users, so I *might* be of some help. :) 1) Installed with QMailToaster (of course!) 2) assign contains 89:89, which maps to vpopmail:vchkuser. 3) all are vpopmail:vchkpw 700. 4) # grep alias /etc/passwd alias:x:7790:2108:qmail alias:/var/qmail/alias:/sbin/nologin # ls -ld /var/qmail/alias drwxr-sr-x 2 alias qmail 4096 Aug 4 2012 /var/qmail/alias # ls -l /var/qmail/alias/.qmail* -rw-r--r-- 1 alias nofiles 34 Jan 8 2010 /var/qmail/alias/.qmail-mailer-daemon -rw-r--r-- 1 alias nofiles 34 Jan 8 2010 /var/qmail/alias/.qmail-postmaster -rw-r--r-- 1 alias nofiles 34 Jan 8 2010 /var/qmail/alias/.qmail-root (group 2107 is nofiles, 2108 is qmail) Are your messages not making to the queue? -rws--x--x 1 qmailq qmail 24776 Aug 4 2012 qmail-queue I ask because I would think that once they're in the queue, you'd be home free. If they're being rejected at smtp time, I wouldn't expect them to be making it to the queue. I'll be delving deeper into qmail later this week, and will post if any lights come on. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] rDNS checking of MX records
I'm with you. I came across a mail server which was (reportedly) checking the rDNS for the IP corresponding to the A record which the MX pointed to. This was an entirely different host than the one sending the message. I realize MX is only used for incoming messages, and thought it was a rather pointless check. Perhaps it was a misconfigured email gateway of some sort. I just wondered if it might be a legitimate thing to check. It's sort of like saying I'm going to check your incoming configuration for errors before I accept a message from your domain. Rather pointless in some senses. In any case, to implement this, spamdyke would do an rDNS check on the IP address corresponding to each MX name, and also check to be sure the rDNS name resolves. It would be (one or) two additional DNS lookups per MX, and would only make sense to do when reject-missing-sender-mx is in effect. It would be something like reject-empty-sender-mx-rdns and reject-unresolvable-sender-mx-rdns. I just don't know if this check would be worthwhile or not. Definitely a low priority. Thanks Sam! -- -Eric 'shubes' On 10/03/2013 08:27 PM, Sam Clippinger wrote: I'm not exactly sure what you're describing here. MX records are supposed to be names, not IP addresses. spamdyke's reject-missing-sender-mx option already checks for the existence of an MX record, then tries to resolve each name to an IP address. I'm not sure I would see the point in trying to resolve each IP address' reverse DNS name; reverse DNS is generally required for IP addresses where email connections originate, not where they terminate. In other words, outgoing servers should have valid rDNS, but incoming servers aren't required to have it -- if a server is willing to accept email, that's not necessarily an indication it's a spam source. Some DNS administrators mistakenly set their MX records to contain IP addresses. This is technically illegal, but spamdyke honors them as valid with no further checking. So anyway, I think I'm misunderstanding what you're asking for. :) -- Sam Clippinger On Oct 3, 2013, at 7:16 PM, Eric Shubert wrote: I don't know if this has come up before, but it just came to my attention that there are some mail servers which check rDNS of domain MX records before accepting emails. I don't believe spamdyke does this. Is this a total waste, or would it perhaps catch some spammers? Some domains have many MX records. I wonder if all MXs are checked, or only the highest priority? Seems like a bit of a waste of resources to me. Any thoughts about this? (I'd certainly prefer to see SPF implemented than MX rDNS checking!) Thanks Sam (and everyone). -- -Eric 'shubes' ___ 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] rDNS checking of MX records
Thanks Sam. I was thinking pretty much the same thing. P.S. Looking forward to the next spamdyke release! :) -- -Eric 'shubes' On 10/04/2013 01:53 PM, Sam Clippinger wrote: OK, I get it. In other words, check the MX exists, that the MX names all have IPs AND that all of those IPs have rDNS names. Right now, spamdyke only checks that an MX exists and at least one of the MX names has an IP. If the test were written to enforce all servers must have instead of at least one server must have, checking rDNS could generate a whole lot more DNS traffic, especially from large senders with lots of servers (e.g. Gmail). I don't really think it would do any good to run that check -- the false positive rate would likely be pretty high (and very difficult to explain to blocked senders). I think it's enough to check the rDNS name of the actual incoming IP and leave it at that. I suppose this could be tested by going through a collection of both spam and ham to run this additional check on the originating servers. It wouldn't be too hard to whip up a shell script to generate numbers for each collection of messages, if someone were interested. -- Sam Clippinger On Oct 4, 2013, at 2:44 PM, Eric Shubert wrote: I'm with you. I came across a mail server which was (reportedly) checking the rDNS for the IP corresponding to the A record which the MX pointed to. This was an entirely different host than the one sending the message. I realize MX is only used for incoming messages, and thought it was a rather pointless check. Perhaps it was a misconfigured email gateway of some sort. I just wondered if it might be a legitimate thing to check. It's sort of like saying I'm going to check your incoming configuration for errors before I accept a message from your domain. Rather pointless in some senses. In any case, to implement this, spamdyke would do an rDNS check on the IP address corresponding to each MX name, and also check to be sure the rDNS name resolves. It would be (one or) two additional DNS lookups per MX, and would only make sense to do when reject-missing-sender-mx is in effect. It would be something like reject-empty-sender-mx-rdns and reject-unresolvable-sender-mx-rdns. I just don't know if this check would be worthwhile or not. Definitely a low priority. Thanks Sam! -- -Eric 'shubes' On 10/03/2013 08:27 PM, Sam Clippinger wrote: I'm not exactly sure what you're describing here. MX records are supposed to be names, not IP addresses. spamdyke's reject-missing-sender-mx option already checks for the existence of an MX record, then tries to resolve each name to an IP address. I'm not sure I would see the point in trying to resolve each IP address' reverse DNS name; reverse DNS is generally required for IP addresses where email connections originate, not where they terminate. In other words, outgoing servers should have valid rDNS, but incoming servers aren't required to have it -- if a server is willing to accept email, that's not necessarily an indication it's a spam source. Some DNS administrators mistakenly set their MX records to contain IP addresses. This is technically illegal, but spamdyke honors them as valid with no further checking. So anyway, I think I'm misunderstanding what you're asking for. :) -- Sam Clippinger On Oct 3, 2013, at 7:16 PM, Eric Shubert wrote: I don't know if this has come up before, but it just came to my attention that there are some mail servers which check rDNS of domain MX records before accepting emails. I don't believe spamdyke does this. Is this a total waste, or would it perhaps catch some spammers? Some domains have many MX records. I wonder if all MXs are checked, or only the highest priority? Seems like a bit of a waste of resources to me. Any thoughts about this? (I'd certainly prefer to see SPF implemented than MX rDNS checking!) Thanks Sam (and everyone). -- -Eric 'shubes' ___ 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] rDNS checking of MX records
Just a follow-up. It's Telstra, Australia's largest Telco, that's doing this. Perhaps it deserves a closer look. Again, not a high priority. -- -Eric 'shubes' On 10/04/2013 01:53 PM, Sam Clippinger wrote: OK, I get it. In other words, check the MX exists, that the MX names all have IPs AND that all of those IPs have rDNS names. Right now, spamdyke only checks that an MX exists and at least one of the MX names has an IP. If the test were written to enforce all servers must have instead of at least one server must have, checking rDNS could generate a whole lot more DNS traffic, especially from large senders with lots of servers (e.g. Gmail). I don't really think it would do any good to run that check -- the false positive rate would likely be pretty high (and very difficult to explain to blocked senders). I think it's enough to check the rDNS name of the actual incoming IP and leave it at that. I suppose this could be tested by going through a collection of both spam and ham to run this additional check on the originating servers. It wouldn't be too hard to whip up a shell script to generate numbers for each collection of messages, if someone were interested. -- Sam Clippinger On Oct 4, 2013, at 2:44 PM, Eric Shubert wrote: I'm with you. I came across a mail server which was (reportedly) checking the rDNS for the IP corresponding to the A record which the MX pointed to. This was an entirely different host than the one sending the message. I realize MX is only used for incoming messages, and thought it was a rather pointless check. Perhaps it was a misconfigured email gateway of some sort. I just wondered if it might be a legitimate thing to check. It's sort of like saying I'm going to check your incoming configuration for errors before I accept a message from your domain. Rather pointless in some senses. In any case, to implement this, spamdyke would do an rDNS check on the IP address corresponding to each MX name, and also check to be sure the rDNS name resolves. It would be (one or) two additional DNS lookups per MX, and would only make sense to do when reject-missing-sender-mx is in effect. It would be something like reject-empty-sender-mx-rdns and reject-unresolvable-sender-mx-rdns. I just don't know if this check would be worthwhile or not. Definitely a low priority. Thanks Sam! -- -Eric 'shubes' On 10/03/2013 08:27 PM, Sam Clippinger wrote: I'm not exactly sure what you're describing here. MX records are supposed to be names, not IP addresses. spamdyke's reject-missing-sender-mx option already checks for the existence of an MX record, then tries to resolve each name to an IP address. I'm not sure I would see the point in trying to resolve each IP address' reverse DNS name; reverse DNS is generally required for IP addresses where email connections originate, not where they terminate. In other words, outgoing servers should have valid rDNS, but incoming servers aren't required to have it -- if a server is willing to accept email, that's not necessarily an indication it's a spam source. Some DNS administrators mistakenly set their MX records to contain IP addresses. This is technically illegal, but spamdyke honors them as valid with no further checking. So anyway, I think I'm misunderstanding what you're asking for. :) -- Sam Clippinger On Oct 3, 2013, at 7:16 PM, Eric Shubert wrote: I don't know if this has come up before, but it just came to my attention that there are some mail servers which check rDNS of domain MX records before accepting emails. I don't believe spamdyke does this. Is this a total waste, or would it perhaps catch some spammers? Some domains have many MX records. I wonder if all MXs are checked, or only the highest priority? Seems like a bit of a waste of resources to me. Any thoughts about this? (I'd certainly prefer to see SPF implemented than MX rDNS checking!) Thanks Sam (and everyone). -- -Eric 'shubes' ___ 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] rDNS checking of MX records
I don't know if this has come up before, but it just came to my attention that there are some mail servers which check rDNS of domain MX records before accepting emails. I don't believe spamdyke does this. Is this a total waste, or would it perhaps catch some spammers? Some domains have many MX records. I wonder if all MXs are checked, or only the highest priority? Seems like a bit of a waste of resources to me. Any thoughts about this? (I'd certainly prefer to see SPF implemented than MX rDNS checking!) Thanks Sam (and everyone). -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Why do some emails not get caught by spamdyke?
On 09/28/2013 04:18 AM, emailitis.com wrote: Can anyone explain why an email got through at 10:03 but then got deleted with RBL_MATCH after that? Could it be that we really got one of the first ones at 10:03?? Sep 28 10:03:43 plesk3 spamd[25071]: spamd: checking message 23724365074273237228913611622...@vzcjfjoxz.ateidantco.us for qscand:10124 Sep 28 10:03:44 plesk3 spamd[25071]: spamd: result: . 1 - HTML_EXTRA_CLOSE,HTML_MESSAGE,RDNS_NONE scantime=1.2,size=9263,user=qscand,uid=10124,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=42980,mid=23724365074273237228913611622...@vzcjfjoxz.ateidantco.us,autolearn=disabled Sep 28 10:03:44 plesk3 spamdyke[32104]: ALLOWED from: testo...@ateidantco.us to: use...@domain1.com origin_ip: 91.218.245.67 origin_rdns: (unknown) auth: (unknown) encryption: (none) reason: 250_ok_1380359024_qp_32111 Sep 28 10:57:05 plesk3 spamdyke[4163]: DENIED_RBL_MATCH from: testo...@ateidantco.us to: t...@domain2.com origin_ip: 91.218.245.67 origin_rdns: (unknown) auth: (unknown) encryption: (none) reason: Sep 28 11:22:23 plesk3 spamdyke[7757]: DENIED_RBL_MATCH from: testo...@ateidantco.us to: use...@hostname.com origin_ip: 91.218.245.67 origin_rdns: (unknown) auth: (unknown) encryption: (none) reason: Kind Regards, Christoph ___ I don't know why not (iow, yes). Is your spamdyke up to date? You should see the rbl which lists the IP in the reason: field of the log message (very nice feature). -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] dns-blacklist-entry
On 09/06/2013 08:42 PM, Nicholas Chua wrote: snip All filters are disabled for authenticated users. Make sure their clients are authenticating when sending. Thanks Eric for your reply. In the first place, i did not enable this filter. Sorry I missed that bit. It really doesn't matter which filter might be blocking though. If they authenticate successfully, no filters are applied, and they should be able to send. This is by design. Secondly i am sure they are authenticated because they had tried to reply to downloaded emails. Authentication for retrieving emails (pop3, imap) is separate from authentication for sending. Even when their client is able to retrieve emails successfully, the client may not be configured to authenticate when sending. Note, POP before SMTP authentication will probably not work by default. See http://www.qmailrocks.org/smtpauth.htm I even encountered spamdyke blocked user from setting up his email account. We would need to see more details regarding this in order to determine what happened, such as which client app they were trying to set up, and spamdyke log message(s) which corresponds to the event. Spamdyke always logs every connection. I have no control of the ISP they use. They are using their personal mobile with comes with data usage I understand this, and spamdyke works well in these situations. If you were to post your spamdyke configuration file perhaps we could be more helpful. I still believe the problem most likely is the client isn't configured to authenticate properly. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] dns-blacklist-entry
On 09/05/2013 09:03 PM, Nicholas Chua wrote: Hi, I did not enabled dns-blacklist-entry but roaming users using a blacklisted IP address is unable to send out their emails. Is it due to dns-blacklist-entry? I had tested the mail server to run without spamdyke and their mails are able to go through. How can i overcome this? Thanks nic ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users All filters are disabled for authenticated users. Make sure their clients are authenticating when sending. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Blacklisting 127.0.0.1
On 08/18/2013 10:15 AM, BC wrote: How about if I put 127.0.0.1 into the blacklist_ip file? Potential downsides? Not that I can think of. Funny though, that I have that ip whitelisted, for fetchmail. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] TLS errors - again
On 06/27/2013 02:27 AM, Faris Raouf wrote: Hmm.. I spoke to soon. I've tried it on a system without qmail-scanner and still get: ERROR: unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found The messages do seem to be getting into mailboxes though. Which version of OpenSSL libraries? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] TLS errors - again
On 06/26/2013 07:11 AM, Faris Raouf wrote: This is a bit of a long message and is on a topic that has been discussed a few times in the past - sorry L I’ve just installed spamdyke on a particular server. Unlike every other spamdyke installation I’ve ever done, this one is generating various TLS errors when receiving mail via TLS connections. There is nothing unusual about this server. Like the rest of the spamdyke-enabled machines I deal with, it uses Plesk 10.4.4, Plesk’s qmail implementation, and qmail-scanner. It does use Centos 5 as opposed to Centos 6 though. The error messages vary from connection to connection, but are usually one or more of the following: ERROR: unable to write to SSL/TLS stream: The operation failed due to an I/O error, Connection reset by peer ERROR: unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found ERROR: unable to read from SSL/TLS stream: The connection was unexpectedly ended/closed The last error is one that I can generate at will by sending a message from one of my other qmail-based servers to this problem server. In all the tests that I’ve done from my server to the problem server, the email in question does arrive in the recipient’s mailbox. For the other two types of error, all I know for sure is that the email does at least get to qmail-scanner for spam/virus checking and it does seem to be arriving in the recipient’s mailbox (but I have not absolutely made sure it happens on every occasion). (Qmail-scanner works via a wrapper around the normal qmail-whateveritis file, and rejects messages at what I refer to as the “MTA level” – i.e. it rejects while the sending server is still connected, just like spamdyke, as opposed to accepting the email then processing it and later dropping it if the message is considered spam or contains a virus) I’ve read every thread I could find via google where people have been having various spamdyke TLS issues in the past, but there didn’t seem to be a conclusive suggestion or solution – at least not one I could find. The posts mentioning TLS errors also seemed to be slightly different to my issue, in that email didn’t seem to be arriving in the recipient’s mailbox (I think). Given that this list is populated with people who live and breath qmail and spamdyke, and that I might have missed a vital post from the past, I was hoping someone could offer some advice on this issue. Thanks, Faris. ** additional info ** In the process of writing this email, I did discover why this server is acting differently to all the others: When a TLS connection happens on the other servers, I see this: encryption: TLS_PASSTHROUGH But on the problem server, I see this: encryption: TLS This is VERY interesting. TLS_PASSTHROUGH means the client started a TLS with qmail, not spamdyke, and explains why the other servers don’t generate any spamdyke tls errors. Exactly why there is this difference in the way TLS is handled is a mystery to investigate another day, I think. ** using --config-test gives a clean bill of health, including the qmail .pem certificate location. tls-certificate-file=/var/qmail/control/servercert.pem (this is the only tls-related option I have added in spamdyke.conf) I’m using exactly the same config in both spamdyke.conf and /etc/xinetd/smtp[s]_psa for all servers. log-level=debug gives no additional useful info compared to verbose The certificate in use is an expired self-signed certificate (there was some talk that TLS errors might be caused by the certificate in some past posts I found, but this possibility seems to have been discounted in the end, I think?) ___ Please answer for both new and existing servers. What is the tls-level you have in the configuration file? Are you certain that spamdyke was built with TLS support? Of course, something's must be different between the old and new. Keep hunting. Might also check library versions. Was spamdyke built on the errant host, or perhaps copied from another host which has different OpenSSL library versions? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] TLS errors - again
On 06/26/2013 01:10 PM, Faris Raouf wrote: Please answer for both new and existing servers. What is the tls-level you have in the configuration file? None at all -- as in I don't have a tls-level option set on any system. Given the way things behave, I'm assuming the default is smtp? I can't tell from the docs. While the docs don't specify a default value, I think no value is the default. The doc says: spamdyke supports TLS in several ways. First, with no TLS options given, spamdyke will identify a TLS conversation and simply pass the data back and forth between qmail and the remote client. In this mode, spamdyke cannot read the SMTP data (obviously -- it's encrypted). This prevents some of its filters from functioning, including graylisting, sender and recipient blacklisting, limiting the number of recipients, checking the sender's domain name for an MX record and relaying. On this issue, is it necessary to specifically specify smtps (note the s) for the service that listens on port 465? I believe so. The way Plesk does things is to have two separate services (or whatever they are called): smtp_psa (listening on port 25) and smtps_psa (465) run via xinetd. Currently, both have the same spamdyke config being used so both are using whatever the default really is. I don't use Plesk, but I believe you need a separate config to run smtps. I will try manually specifying smtp to start with to see if it makes any difference, but I'm guessing it won't. I'll report back on this. FWIW, here's what I use (no 465 in my world though) tls-certificate-file=/var/qmail/control/servercert.pem tls-level=smtp Are you certain that spamdyke was built with TLS support? Having checked, the server causing me problems says spamdyke 4.3.1+TLS+CONFIGTEST+DEBUG while the ones that don't (i.e. the TLS_PASSTHOUGH ones say spamdyke 4.3.1+CONFIGTEST+DEBUG so I think that proves those other ones didn't have the required libraries and basically aren't going to do TLS. Thank you for this pointer. Excellent! Right on. Unless of course your version of qmail-smtpd has the TLS patch and is handling it. So, that brings us back to the main problem of WHY I'm seeing the errors: ERROR: unable to write to SSL/TLS stream: The operation failed due to an I/O error, Connection reset by peer ERROR: unable to read from SSL/TLS stream: The operation failed due to an I/O error, Unexpected EOF found ERROR: unable to read from SSL/TLS stream: The connection was unexpectedly ended/closed I wonder if it is a result of qmail-scanner's interaction with the data stream in some way? I take it nobody else gets them, and since qmail-scanner isn't widely used by people in this list, I may be out of luck for an easy just do this answer :-) Perhaps so. I'm not familiar with how qmail-scanner is invoked. Don't let that deter you though. I'll see if I can remove qmail-scanner temporarily without totally breaking things. I fear it is not as simple as it might be. Worth a shot. Thank you for your input -- it has been really useful and has got me looking in places I didn't think of looking :-) :-) Certainly. Glad to help. Every little thing we do to help ourselves also helps Sam, which I think everyone agrees is a good thing. :) -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] TIMEOUT
On 06/21/2013 02:20 PM, Eric Broch wrote: Hello List, I have the following error in Spamdyke from a valid SMTP server. It seems odd to me that this server would be sending with TLS encryption. Am I correct, is this odd behaviour? Is there a way to remedy this? White Listing the domain did not help. 2013-06-21 11:38:30.167842500 spamdyke[12175]: TIMEOUT from: (unknown) to: (unknown) origin_ip: xxx.xxx.xxx.xxx origin_rdns: securemail.xxx.com auth: (unknown) encryption: TLS reason: TIMEOUT Eric I think quite a few servers send with TLS these days, so I don't think it's odd at all. Timeouts aren't all that uncommon from spammers, but you shouldn't be seeing them from legit senders. I'd check the size of the message if you can (from the sender). It's possible that the sender is timing out while your QMT is scanning it. Be sure your clamav is up to date, and scanning isn't choking things up. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Truncated Log Entries
What are your log related config settings? If log-target is syslog, which syslog software are you using? If log-target is stderr, please include sample of your run file. On 06/17/2013 06:54 AM, Arne Metzger wrote: I dont want to confuse you, so here the log lines without line breaks Jun 17 15:45:51 shjjv spamdyke[9610]: FILTER_RBL_MATCH ip: 203.80.244.134 rbl: zen.spamhaus.org Jun 17 15:45:51 shjjv spamdyke[9610]: DENIED_RBL_MATCH from: m...@con-link.com to: jxxxt-OrRQzMG+/d0b1svskn2...@public.gmane.org origin_ip: 203.80.244.134 origin_rdns: mail.con-link.com auth: (unknown) encryption: (none) reason: zen.^Y Second entry is truncated at ^Y Am 17.06.2013 15:50, schrieb Arne Metzger: Hello, i just wonder why some of my log entries are truncted Jun 17 15:45:51 shjjv spamdyke[9610]: FILTER_RBL_MATCH ip: 203.80.244.134 rbl: z en.spamhaus.org Jun 17 15:45:51 shjjv spamdyke[9610]: DENIED_RBL_MATCH from: m...@con-link.com t o: jx...@sxxv.de origin_ip: 203.80.244.134 origin_rdns: mail.con-link. com auth: (unknown) encryption: (none) reason: zen.^Y Any hints? Regards, Arne PS: Sam, Thank you s much for your fantastic work! I Love spamdyke! ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] blacklists
On 06/03/2013 04:50 PM, Eric Broch wrote: Hello spamdyke users, I have blacklisted several senders and don't wish them to know that they've been blacklisted as they might change domain name etc... Is there a way to simply drop the email silently? Eric I don't believe spamdyke can do this (yet). I think you'd need to implement something on the delivery side of things (post queue). I'd look to see if maildrop can perhaps do this for you. If you're using dovecot, you might consider switching over to dovecot's LDA, and do this filtering with sieve. This is the direction that QMT is headed. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Duplicate ALLOWED from log entries
On 05/23/2013 03:35 PM, Lutz Petersen wrote: Hi, Which in some extreme cases where session had 9000 recipients led to multi GB log file. Imho you should configure your Spamdyke not to accept such nonsense. There is absolute no reason to accept more than a dozen recipients. Use e.g. this in your spamdyke.conf: max-recipients=15 And you'll get off those defect hosts.. Lutz Petersen I agree Lutz, and use this setting myself. I think that Teodor is referring to something different though. While qmail sends only one message per smtp session, the smtp spec allows for multiple messages to be sent in a single smtp session, however rare that might be. I expect this is what Teodor's seeing. The spamdyke docs say that max-recipients is applied to the connection, not each message, so use of this option would certainly help (more so than if it was applied to each message as I believe chkuser does). Sam, will you please confirm that this is per connection and not per message? It appears to me that spamdyke has a bug in how it's logging this type of session. I'm interested to see what Sam finds with this. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Script You Mentioned on the Archive List
I'd like to include this in QMT somewhere. We should look into including it when we put spamdyke in the stock packaging, which I'm hoping will happen sometime this year. Thanks Dave! -- -Eric 'shubes' On 04/09/2013 06:42 PM, David Milholen wrote: That is the ticket.. My turn contribute :) I have a secondary/backup server I will install your script on and allow some production traffic to pass through and I will get started on a time out script for this. Maybe Eric can include this as a whole on the QMT WIKI site. When I can, I will submit a follow up with results. Thanks Dave On 4/9/2013 9:15 AM, Sam Clippinger wrote: It came from pure desperation. IP filtering wasn't doing the trick for me, so I started paying attention to the rDNS names and checking out their websites. When I saw the same site again and again, I knew I had a way to stop them. Then I also noticed that a lot of identical sites were hosted on IPs in the same subnets, so I extended the script to search out neighboring IPs. It works pretty well. The script generates entries in a blacklist directory structure, not a file, so the number of blacklist entries shouldn't be a problem. Because each entry is a separate file, you could write a very simple script to automatically delete any files older than X days. That would make them automatically expire. -- Sam Clippinger On Apr 9, 2013, at 7:08 AM, David Milholen wrote: Very Clever, Where did this idea come from? Also, is there tick timer per IP so as not to load up the blacklist file? I like using the timers in router OS when performing firewall rule sets. Basically lists the bad ip or name for a time limit then drops it but it will get added again if it is still bad. Dave On 1/27/2013 4:00 PM, Sam Clippinger wrote: I've been asked for these scripts a few times and I've finally made the time to package them up. They can be downloaded here: http://www.spamdyke.org/releases/hunter_seeker/ http://www.spamdyke.org/releases/spamtrap/ Of the two, the hunter_seeker script is the most effective. My rDNS blacklist is up to 92500 entries and stops a significant number of incoming messages every day. -- Sam Clippinger On Jan 18, 2013, at 4:44 PM, Denny W. Jones wrote: Mr Clippinger, In this message: http://www.mail-archive.com/spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.org/msg01162.html you refer to a script you wrote for scanning for IP's to blacklist. I was wondering if you were able to make this available for download. I'd be very interested in experimenting with it on my server. Thanks for your time. Denny ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- David Milholen Project Engineer P:501-318-1300 ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.org mailto:spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- David Milholen Project Engineer P:501-318-1300 ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.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] SMTP-AUTH and filters
On 04/08/2013 01:04 PM, Jorge R Constenla wrote: Hi, I have a doubt: If a user authenticates with SMTP auth. All filters are ignored? Yes. If true, Why? Why not? Many users submit from dynamic address locations, which are typically blacklisted. If filters weren't bypassed, they would be unable to submit. What sort of restriction(s) would you like to see for authenticated submissions? You might look into eMPF for these types of needs (policy restrictions). -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] SMTP-AUTH and filters
On 04/08/2013 01:40 PM, Lutz Petersen wrote: What sort of restriction(s) would you like to see for authenticated submissions? You might look into eMPF for these types of needs (policy restrictions). Really simpel: To be safe we in general don't allow clients to access if the ip is listed at spamhaus sbl-xbl. This had good effects. But we have different servers for incoming mail and for client connects and so spamdyke is not involved at the clients servers. In that case, I would set up the old rblsmtpd program in the run file, and specify whatever blacklist(s) you want there. That program will reject regardless of authentication. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] spamdyke and local users
On 03/27/2013 03:33 AM, turgut kalfaoğlu wrote: We also have customers that use POP-Before-SMTP, and not smtp auth. Do I need to do anything for them? I don't believe that spamdyke has any pop-before-smtp authentication capability. I would encourage you to move away from such configurations if at all possible. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] allow incoming mail to specific recipients only from authentificated users
On 02/10/2013 02:05 PM, Arne Metzger wrote: Hello, i have to find a solution for this situation: on my plesk-vserver (qmail and spamdyke) we have several recipients without an assigned mailbox, since we use those addresses only for mail-groups (with both internal and external recipients). now i want to prevent external and unauthenticated SMTP-traffic to those mail-group-addresses. Only authenticated internal users should be allowed to send emails to them. I just did a test and sent a mail from one of my accounts to a test-recipient on my vserver, that has a mail-group assigned. Since my mail comes from an reliable mail-server, all filter of spamdyke passed and my mail was allowed to be delivered to the test-recipient. Is there any way to block connections that pass all filters to specific recipients unless those connections use SMTP-AUTH? Regards, Arne blacklist_recipients? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] allow incoming mail to specific recipients only from authentificated users
Wouldn't blacklisting the recipient address accomplish the same thing? (I'm probably missing something here) -- -Eric 'shubes' On 02/10/2013 03:29 PM, Sam Clippinger wrote: As a matter of fact, there is. First, use a configuration directory to create configuration files for the recipients you want to restrict. For example, if the recipient address is mailing-list-hcdggtzh8xnbdgjk7y7...@public.gmane.org, create a file with this name: /var/qmail/spamdyke/config.d/_recipient_/com/example/_at_/mailing-list (You can choose your own location in your file system if you don't like /var/qmail/spamdyke/config.d.) In that file, put this configuration option: filter-level=require-auth Then add a line to your main spamdyke configuration file to use that folder structure: config-dir=/var/qmail/spamdyke/config.d That's it! Any attempts to send mail to the address will be rejected unless they're authenticated. -- Sam Clippinger On Feb 10, 2013, at 3:05 PM, Arne Metzger wrote: Hello, i have to find a solution for this situation: on my plesk-vserver (qmail and spamdyke) we have several recipients without an assigned mailbox, since we use those addresses only for mail-groups (with both internal and external recipients). now i want to prevent external and unauthenticated SMTP-traffic to those mail-group-addresses. Only authenticated internal users should be allowed to send emails to them. I just did a test and sent a mail from one of my accounts to a test-recipient on my vserver, that has a mail-group assigned. Since my mail comes from an reliable mail-server, all filter of spamdyke passed and my mail was allowed to be delivered to the test-recipient. Is there any way to block connections that pass all filters to specific recipients unless those connections use SMTP-AUTH? Regards, Arne ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.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] Blocking DHCP addresses
I've received a malicious spam from the following address: Received: from unknown (HELO 74-142-212-17.dhcp.insightbb.com) (74.142.212.17) I'm a little surprised that the address hasn't been blacklisted, being an apparent dynamic address. I'm using dns-blacklist-entry=zen.spamhaus.org dns-blacklist-entry=bl.spamcop.net Is there a good way to block public hosts with dhcp in their name? Is there a better approach to this? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Blocking DHCP addresses
On 02/08/2013 09:35 AM, Gary Gendel wrote: On 02/08/2013 11:10 AM, Eric Shubert wrote: I've received a malicious spam from the following address: Received: from unknown (HELO 74-142-212-17.dhcp.insightbb.com) (74.142.212.17) I'm a little surprised that the address hasn't been blacklisted, being an apparent dynamic address. I'm using dns-blacklist-entry=zen.spamhaus.org dns-blacklist-entry=bl.spamcop.net Is there a good way to block public hosts with dhcp in their name? Is there a better approach to this? It doesn't seem to be on any of the blacklists reported by: http://multirbl.valli.org/lookup/74-142-212-17.dhcp.insightbb.com.html I see two possibilities: 1) Add dhcp as an entry in ip-in-rdns-keyword-blacklist- 2) add .dhcp.insightbb.com in rdns-blacklist- (1) may block legitimate addresses from anywhere just because they have dhcp in their rdns name. (2) may block legitimate addresses if any exist within that domain. Gary Thanks Gary. After reading the documentation, I've decided to put dhcp dynamic in my blacklist_keywords file. I haven't used this feature in the past, but upon careful reading, I see that this only blocks when the keyword is present in the rDNS name *and* there is also a match to THE IP address (not just any ol' IP address) in the rDNS name. So (1) is not a concern after all. Great feature, Sam. Thanks! -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Blocking DHCP addresses
On 02/08/2013 10:16 AM, Lutz Petersen wrote: Again: It is a very _bad_ idea to block hosts with the keyword dhcp in the rdns name. A lot of static hosts (hostingcenter etc.) have this keyword in their rdns and they all are static. 74-142-212-17.dhcp.insightbb.com (74.142.212.17) This is listed in the cbl. Only because blacklists need some short time to detect emitting spam ips it is not worth to create filters that gives you al lot of false positives. Lutz Petersen I guess I was one of the unfortunate few who got the email before it was listed in the RBLs. :( I see what you mean, given that all dhcp addresses aren't necessarily dynamic. I commonly use dhcp to assign fixed (non-dynamic) addresses. I suppose that using the keyword dynamic would be safe. It wouldn't have caught this one though. Thanks Lutz. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Blocking DHCP addresses
On 02/08/2013 11:37 AM, Gary Gendel wrote: On 02/08/2013 01:19 PM, Eric Shubert wrote: On 02/08/2013 10:16 AM, Lutz Petersen wrote: Again: It is a very _bad_ idea to block hosts with the keyword dhcp in the rdns name. A lot of static hosts (hostingcenter etc.) have this keyword in their rdns and they all are static. 74-142-212-17.dhcp.insightbb.com (74.142.212.17) This is listed in the cbl. Only because blacklists need some short time to detect emitting spam ips it is not worth to create filters that gives you al lot of false positives. Lutz Petersen I guess I was one of the unfortunate few who got the email before it was listed in the RBLs. :( I see what you mean, given that all dhcp addresses aren't necessarily dynamic. I commonly use dhcp to assign fixed (non-dynamic) addresses. I suppose that using the keyword dynamic would be safe. It wouldn't have caught this one though. Sorry, I've seen a lot of static domains that are really dynamic and visa-versa. Spam control can be a hair-pulling experience. I used to hand-roll my own, tried and discarded many such rules. Spamdyke allowed me to replace it all. The few that get past Spamdyke are mostly caught by SpamAssassin by processing the content of the message. The very small number that get through I don't lose sleep over anymore. Gary Yeah, spamdyke's the bomb. Preaching to the choir here. :) There seems to be a fewer more getting through lately than there used to be though. Used to be near zero, and now I'm noticing maybe one a day. Not so bad really, but I think the spammers are catching on to some things. It's a continual cat-n-mouse game though. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] query, wich is format file whitelist_ip ?
On 01/31/2013 08:51 AM, Linux wrote: Hello friends, I want to include a segment on my whitelist ip but do not know which format to use, this is valid? 192.168.1.0/20 or is another format? Thanks for your help The format is quite flexible: http://www.spamdyke.org/documentation/README_ip_file_format.html -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] query, wich is format file whitelist_ip ?
tcp.smtp is not so flexible. man tcprules says this: Address ranges: tcprules treats 1.2.3.37-53:ins as an abbreviation for the rules 1.2.3.37:ins, 1.2.3.38:ins, and so on up through 1.2.3.53:ins. Simi- larly, 10.2-3.:ins is an abbreviation for 10.2.:ins and 10.3.:ins. On 01/31/2013 09:28 AM, Linux wrote: Sorry my friends for the trouble and being offtopic to spamdyke handled properly so you as the notation of a network segment tcp.smtp? example: 192.168.0.1/19 is HostMin: 192.168.0.1 HostMax: 192.168.31.254 correct notation is 192.168.0-192.168.31.: Allow Is that correct? Thanks and sorry for not being completely on the topic. Best regards, Pablo 2013/1/31 Linux distribucionlinux-re5jqeeqqe8avxtiumw...@public.gmane.org: Eric thank you very much :) , very clarifying your information. Best regards. Pablo 2013/1/31 Eric Shubert ejs-mdyvq9ofcysstnjn9+b...@public.gmane.org: On 01/31/2013 08:51 AM, Linux wrote: Hello friends, I want to include a segment on my whitelist ip but do not know which format to use, this is valid? 192.168.1.0/20 or is another format? Thanks for your help The format is quite flexible: http://www.spamdyke.org/documentation/README_ip_file_format.html -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] I turned on spamdyke and Outlook 2003 does not send mail
Also, I've seen Outlook time out while waiting for large emails to be scanned for viruses (which can result in duplicate messages being sent). I would increase the timeout parameter in Outlook if this is the case. Outlook's timeout setting has no affect on the end user, as Outlook queues outbound messages. -- -Eric 'shubes' On 12/21/2012 11:00 AM, Sam Clippinger wrote: Timeout errors are usually DNS-related. I suggest installing a caching nameserver on your mail server so DNS queries will happen as fast as possible. You can also try telnetting to port 25 on your mail server while spamdyke is enabled to see how long it takes the greeting banner to appear -- that will probably give a good idea what's causing the delay. Also, is there a reason you're not running the latest version of spamdyke? I'd strongly recommend it -- there have been many bug fixes (some of them security related) since version 3.1.8. -- Sam Clippinger On Dec 21, 2012, at 2:55 AM, Giuseppe Perna wrote: Hi all, some days all clients Outlook 2003 can not send mail for a time-out error. This problem only applies to Outlook 2003 and when I turned spamdyke. I've read that to fix it I have to open the door submission 587. There are other solutions? I found another solution, enter the IP of the sender in the file ip-whitelist-file = / etc / spamdyke / whitelist_ip is working properly. I also tried to enter the domain of the sender and the exact address of the sender here sender-whitelist-file = / etc / spamdyke / whitelist_senders but does not work. you have other suggestions? thanks my spamdyke: spamdyke 3.1.8+TLS (C)2007 Sam Clippinger, samc (at) silence (dot) org http://www.spamdyke.org/ spamdyke.conf #check-dnsrbl=zombie.dnsbl.sorbs.net #check-dnsrbl=dul.dnsbl.sorbs.net #check-dnsrbl=bogons.cymru.com check-dnsrbl=zen.spamhaus.org #check-dnsrbl=bl.spamcop.net #check-dnsrbl=list.dsbl.org graylist-dir=/var/spamdyke/graylist graylist-max-secs=2678400 graylist-min-secs=180 greeting-delay-secs=5 idle-timeout-secs=60 ip-blacklist-file=/etc/spamdyke/blacklist_ip ip-in-rdns-keyword-file=/etc/spamdyke/blacklist_keywords ip-whitelist-file=/etc/spamdyke/whitelist_ip local-domains-file=/var/qmail/control/rcpthosts local-domains-file=/var/qmail/control/morercpthosts log-level=2 log-target=0 #log-level=verbose #log-target=stderr #max-recipients=5 max-recipients=30 #policy-url=http://my.policy.explanation.url/ rdns-blacklist-file=/etc/spamdyke/blacklist_rdns rdns-whitelist-file=/etc/spamdyke/whitelist_rdns recipient-blacklist-file=/etc/spamdyke/blacklist_recipients reject-empty-rdns #reject-ip-in-cc-rdns reject-missing-sender-mx reject-unresolvable-rdns sender-blacklist-file=/etc/spamdyke/blacklist_senders sender-whitelist-file=/etc/spamdyke/whitelist_senders tls-certificate-file=/var/qmail/control/servercert.pem ___ spamdyke-users mailing list spamdyke-users-/x2b3zmi7jpg9huczpv...@public.gmane.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] Apparent Relay Rule discrepancy
As much as I dislike using tcp.smtp rules, I'm looking into them more in detail now. According to spamdyke's documentation, spamdyke uses exactly the format tcpserver uses for rules. In man tcprules regarding addresses (first part of rule), it says: shorter and shorter suffixes of $TCPREMOTEHOST starting with a dot, preceded by =, if $TCPREMOTEHOST is set; In the spamdyke documentation, examples are: =mail.example.com:allow,FOOVAR=foovalue,BARVAR=.barvalue.,BAZVAR=-bazvalue- =.example.com:allow,FOOVAR=foovalue,BARVAR=.barvalue.,BAZVAR=-bazvalue- =.com:allow,FOOVAR=foovalue,BARVAR=.barvalue.,BAZVAR=-bazvalue- Shouldn't the last 2 examples here begin with = instead of just =? Is this simply an error in the documentation, or also a bug? Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] How best to whitelist rejected emails
On 09/16/2012 03:38 PM, g...@genashor.com wrote: Some RBLs block yahoo because spammers really love to use it. I feel that this is way too aggressive and any blacklist that blocks like this I avoid. Me too. I use only: dns-blacklist-entry=zen.spamhaus.org dns-blacklist-entry=bl.spamcop.net These have *very* few FPs. However, I do have yahoo in my rdns whitelist anyway since I use that to avoid putting things on the graylist. This way I can use the graylist more effectively to see if my spamdyke rejection strategy is working well. I've been running w/out graylisting lately. It doesn't seem to be all that effective on top of spamdyke's other filters, and the delays can be annoying at times. On Sep 16, 2012 6:02 PM, emailitis.com off...@emailitis.com wrote: Thank you Sam for your speedy response. How can I tell if I have the latest version? Can you tell me what shell command to run? # spamdyke -v And to update, is it simply “yum upgrade spamdyke”? That's doubtful. Install the latest version in the same way the current one was done. Note, you'll need to review your configuration settings if you're upgrading from a pre-4.x release, as there are some incompatibilities between major releases. I do not want to whitelist the whole btinternet.com domain as there will be Spam. I really like your idea to “use a configuration directory to whitelist any sender within btinternet.com http://btinternet.com when the rDNS of the server is within yahoo.com http://yahoo.com”. Can you tell me how to do that please? Configuration directories are not exactly simple, and I try to avoid them at pretty much all costs (I still don't use them). I think you'll be better off identifying the RBL that's rejecting yahoo addresses, and discontinue using that, as Gary suggested. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Where to run the caching DNS resolver
You've got the right idea. Implementing it isn't trivial though, and I wouldn't recommend putting all those eggs in one basket (on the same host), unless you use a virtual platform to do so. I recommend you look into IPCop or pfSense for a firewall host. You can put IPCop on an old PII or PIII host. It only takes 128M of ram, and a 1G HDD would do fine. These distros are robust network service hosts (router/firewall/vpn/dhcp - you name it). BL, you really don't want your mail server (or any server for that matter) handling network security. Apply the KISS rule whenever possible. -- -Eric 'shubes' On 09/03/2012 01:52 PM, BC wrote: This is probably over my head. From my reading about a DMZ, that would require using a 3rd NIC on the host machine, right? I have a mobo NIC that I'm not using presently and could assign it an address of say, 10.10.0.1 (the LAN is 10.0.0.1) Presently, everything that is running on the host machine is basically attached to the 10.0.0.1 IP address in some way or another. For a short time I experimented with tinydns and ran it on the 127.0.0.1 IP on the host, but I don't use local dns hosting. So, if I'm understanding you the proper way to do this would be like so: _ LAN (10.0.0.1) - all the processes needed (dhcp, resolver), various Windows machines... / WAN (internet)/ \ \__DMZ (10.10.0.1) - email server, spamdyke, separate resolving cache Do I have this right? Then I'd punch a hole through the firewall between 10.0.0.1 and 10.10.0.1 so I could do my email via the LAN? On 9/3/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: Here's the thing. Your mail server should be on the DMZ subnet (I'm not sure of PF's terminology). That subnet has no access to dhcp or resolvers, for security reasons. I suppose you could punch a pinhole for DNS requests, but that sort of defeats the purpose. Since all hosts in the DMZ should use a resolver/recursor which is not on the (trusted) LAN, they can a) use their own, b) use a common one on the DMZ subnet (but preferably*not* an authoritative DNS host), or c) use one provided by an ISP or other service (OpenDNS and Google provide several free ones). The options are in order of efficiency, and probably preference as well for most cases. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DDOS Help
On 09/01/2012 08:17 AM, J.R. Lillard wrote: I have a client that uses spamdyke but I am new to it. I've read through the documentation so I am vaguely familiar with it now. They have been under a DDOS attack for about a month now. It's not enough to bring their servers down. Basically it's a bunch of SMTP traffic attempting to send spam. Spamdyke has been doing a great job of blocking the connections usually with the DENIED_RDNS_MISSING error. The problem is this attack has been eating up a lot of their bandwidth. As a temporary measure their ISP has asked them to just drop the invalid connections instead of issuing the appropriate SMTP response codes. Is this something spamdyke can be configured to do? I did not see anything obvious in the documentation. -- J.R. Lillard System / Network Admin Web Programmer Hyphen Communications ___ Hey JR, I don't know the answer to this question. Sam will no doubt chime in on spamdyke's capability regarding dropping connections. My opinion is that this would not be an appropriate thing to do. Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents of /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic can be reduced a bit by running a resolver on localhost (127.0.0.1). Personally, I use the pdns-recursor package on CentOS. I expect that there's probably a powerdns recursor available for your platform as well. You'll also want to check that you're not using too many dns-blacklist-entry= parameters. In this area, more isn't necessarily better. Personally, I use only zen.spamhaus.org and bl.spamcop.net. While DNS traffic isn't large from a bandwidth standpoint, I expect that it's larger than SMTP response codes. If the DDOS attacks are coming from a single group of IP addresses, having a caching nameserver on localhost will provide a substantial reduction in network/DNS traffic. HTH. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Where to run the caching DNS resolver
Sam's right of course. :) I think the question might have been (as I read it) regarding a configuration where the resolver is on the local network (private lan), but not on the host which is running spamdyke (not accessible as 127.0.0.1). This is not as ideal as having the resolver running on spamdyke's host, as all DNS traffic hits the wire in this case. However, cached requests don't make it out to the ISP, so it would help in that regard. If your LAN isn't hurting for bandwidth, this setup could be sufficient, but it's not ideal. I hope this makes sense. -- -Eric 'shubes' On 09/01/2012 02:10 PM, Sam Clippinger wrote: If 10.0.0.1 is the IP of the local host on the LAN, it shouldn't matter at all. The OS will realize the IP address is assigned to the local NIC and won't send any packets across the wire. The only reason it might be a problem would be if your firewall is configured to block incoming DNS requests from your LAN, but in that case you would realize the mistake immediately because no DNS queries would ever succeed. :) -- Sam Clippinger On Sep 1, 2012, at 12:39 PM, BC wrote: A novice question perhaps, but does it matter much where one runs the local caching resolver? I have a LAN with IP 10.x.x.x and simply use 10.0.0.1 as the local IP for the resolver. My understanding is that any local IP can be used so long as it can be reached by those functions needing access to it. Would I gain any advantage by using 127.0.0.1 instead? On 9/1/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: Given what you've described, I would consider whether the host is running a caching nameserver or not. What are the contents of /etc/resolv.conf ? spamdyke is rather heavy on DNS, and network traffic can be reduced a bit by running a resolver on localhost (127.0.0.1). ___ 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] Where to run the caching DNS resolver
On 09/01/2012 08:17 PM, BC wrote: I think I understand what you are saying. My local LAN is quite simple: only one *nix box and it sits between the internet source and the rest of the machines on my LAN. That one box contains two NICs - the public (WAN-side NIC) and the private (LAN-side NIC) and runs spamdyke (as well as myriad other processes including qmail). The LAN-side NIC is the 10.0.0.1 IP and that is where the resolving cache runs. The box owns the 127.0.0.1 IP, right, just as every over box on the LAN has its own 127.0.0.1 (local host)? Right. I'm presuming that if I had a second *nix box on the LAN and was running spamdyke over there, then I'd potentially be creating a lag time in responsiveness. True. Am I understanding what you are saying? Yep. PS - my email server has only one customer, me. That's how I started as well. :) You might want to consider putting an IPCop (or other suitable firewall) host on your perimeter. I think it's the next logical step for your situation. On 9/1/2012 8:38 PM, spamdyke-users-requ...@spamdyke.org wrote: I think the question might have been (as I read it) regarding a configuration where the resolver is on the local network (private lan), but not on the host which is running spamdyke (not accessible as 127.0.0.1). This is not as ideal as having the resolver running on spamdyke's host, as all DNS traffic hits the wire in this case. However, cached requests don't make it out to the ISP, so it would help in that regard. If your LAN isn't hurting for bandwidth, this setup could be sufficient, but it's not ideal. I hope this makes sense. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] mx = 0 or mx = 127.0.0.1
On 08/21/2012 07:51 AM, Marcin Orlowski wrote: Bruce Schreiber wrote on 2012-08-21 16:37: Is there a way to block domains that have mx records of either 0 or 127.0.0.1. Both entries can be found in DNS and give us a headache. Look at yahool.com yaho.com version.net as problem domains. Heh, that's clever :) I do not see any option for that, yet adding to the code should be quite easy. Regards, That's totally illegal (not that it doesn't occur). MX records should only point to A records. I suppose that spamdyke should also (at least have an option to) check that the A record exists (the MX resolves), much like it does for rDNS. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] TODO.txt (enhancement) priorities
Understood. Thanks. On 07/30/2012 11:02 AM, Sam Clippinger wrote: I imagine whenever I get around to implementing SPF and DKIM, I'll add some options to specify what to do with matching connections -- whether they should be blocked if they don't match, if headers should be added, if they should always be trusted, etc. I can make the change in the TODO file, but honestly I have so little time to work on spamdyke these days that any discussion of priority is mostly academic. :) Hopefully that will change before the end of the year... -- Sam Clippinger On Jul 28, 2012, at 5:08 PM, Eric Shubert wrote: FWIW, I would like to see the DKIM/SPF suport... TODO item moved under Highest Priorities, perhaps replacing Full database support. While DKIM/SPF might not make a huge impact on reducing spam (how much better can it possibly get?), being able to whitelist trusted domains (e.g. banks) according to their published SPF record would make whitelisting much simpler. For example, [root@tacs-mail spamdyke]# host -t txt jpmchase.com jpmchase.com descriptive text v=spf1 a:spf.jpmchase.com ip4:207.162.228.0/24 ip4:207.162.229.0/24 ip4:207.162.225.0/24 ip4:196.37.232.50 ip4:159.53.46.0/24 ip4:159.53.36.0/24 ip4:159.53.110.0/24 ip4:159.53.78.0/24 include:tpo.chase.com -all This results in quite a number of whitelist entries when whitelisting by IP address (which I think is probably the best method in this case). Plus the fact that Chase isn't in the habit of letting me know when they change their outbound servers. ;) (I know, I could write a script that would let me know this) I would love to be able to have a whitelist_spf_domain_file option where I could list domains that I trust, and have spamdyke auto-whitelist any server that's listed in their SPF record. This would be a powerful feature, which would make whitelisting easier to admin, maintain, and (arguably) more secure. Thanks for your consideration on this, Sam, as well as your great work with spamdyke. We all greatly appreciate what you do. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Problems with spamdyke recipient blacklist
Not that it matters, but I agree with Sam on this. Personally, I don't whitelist yahoo.com, and I wouldn't use a dnswl that included them (nor any other major ESP). Let the chips otherwise fall where they may. If one of yahoo's IPs happens to get blacklisted, there's likely a good reason for it, and they should clean up their mess. Does anyone use yahoo for serious email any more? In your situation, I think use of the badmailfrom file is entirely appropriate. I still use it for a few things. -- -Eric 'shubes' On 07/30/2012 10:51 AM, Sam Clippinger wrote: I understand what you're saying -- whitelists shouldn't always override blacklists. But if I tried to change this, how would it work? Perhaps whitelisting a specific address (e.g. u...@domain.com) would override a domain blacklist (e.g. @domain.com) while blacklisting a specific address would override a domain whitelist? But what about all the other blacklist/whitelist options? Do DNS RBLs override DNS RHSWLs? Do rDNS blacklists override IP whitelists? Do entries in configuration directories override entries from the global configuration file? Should the order of priorities itself be configurable? Overall this looks like a troubleshooting nightmare to me -- an administrator would never be able to understand whether a whitelist had priority over a blacklist without rereading the documentation (and possibly testing it to be sure). I understand the problem you're facing, but I think making blacklists override whitelists some of the time would cause a lot more problems than it would solve. -- Sam Clippinger On Jul 29, 2012, at 5:04 AM, Lutz Petersen wrote: Hi, I've some trouble with spamdykes recipient blacklist option. Let me give you an example: Recipients domain is @domain.tld Now theres flooding in senseless mails for nonse...@domain.tld and I made an blacklist entry for this recipient. This works fine for a lot of cases. But, for example, all mails from the spamfree yahoo community (thats a joke if you don't understand..) will get through. This is because any kind of whitelist match overwrite any kind of blacklist match within the spamdyke logic. And well known mailservers like that one from yahoo naturally are within our own dns whitelist (to prevent blocking) or in others like dnswl.org etc. I don't see the sense why an explicit 'blacklist recipient' entry should ever be overwritten from any whitelisting. The only solution I found for this special case (beware, this single case made some 1 senseless emails every day) was to add this single recipient address not in spamdyke but in qmail's badmailfrom file. Lutz Petersen ___ 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] Relaying - documentation clarification
Just to be clear though, at some point in the future (hopefully next release) this behavior will change, and whitelisting will have no longer have any effect on relaying, regardless of whether spamdyke or qmail controls relaying. Correct? On 07/30/2012 10:22 AM, Sam Clippinger wrote: Correct -- whitelisted connections are only allowed to relay when spamdyke is controlling relaying (i.e. it has both the access-file and local-domains-file options). -- Sam Clippinger On Jul 28, 2012, at 2:45 PM, Eric Shubert wrote: While (re)reading the documentation here: http://spamdyke.org/documentation/README.html#RELAYING I noticed the following about the relay-level setting: normal: Prevent relaying according to the contents of the access file and the list of local domains. Authenticated and whitelisted connections will be allowed to relay. This is the default. Whitelisted connections are only allowed to relay when spamdyke controls authentication, no? Just to repeat my position, I think for consistency and security's sake, whitelisted connections should have no effect on relaying. Authentication and access file settings are sufficient to control relaying. This way, whitelisting works the same regardless of which authentication mechanism is used. In either case, I think the documentation could stand to be modified. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Relaying - documentation clarification
While (re)reading the documentation here: http://spamdyke.org/documentation/README.html#RELAYING I noticed the following about the relay-level setting: normal: Prevent relaying according to the contents of the access file and the list of local domains. Authenticated and whitelisted connections will be allowed to relay. This is the default. Whitelisted connections are only allowed to relay when spamdyke controls authentication, no? Just to repeat my position, I think for consistency and security's sake, whitelisted connections should have no effect on relaying. Authentication and access file settings are sufficient to control relaying. This way, whitelisting works the same regardless of which authentication mechanism is used. In either case, I think the documentation could stand to be modified. Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] spamassassin not running with spamdyke's access-file
Sam, Thanks so much for your very clear and thoughtful reply. I'll comment as we go this time so I don't need to establish context. On 07/26/2012 02:12 PM, Sam Clippinger wrote: You have not yet begun to try my patience. :) I'm certainly glad for that! :) I hope you'll not hesitate to let me know if and when I do. I guess I just don't understand the full difference between the way you think of whitelisting and authentication. Sometimes I don't either. ;) I guess I never thought of whitelisting having an effect on relaying, probably because it never did before. I've always thought that authentication and tcp.smtp rules were the only things that affected relaying. Here's how I think of them: When I have a machine (e.g. a web server) that needs to send mail using my mail server without being blocked, I whitelist it. That bypasses all of the spam filters and allows the remote machine to send email to remote recipients (relaying). In the absence of spamdyke, I would add that machine's IP address to my /etc/tcp.smtp file instead. I've typically done the later, as whitelisting with spamdyke to accomplish this only works when spamdyke is handling authentication (and thus relaying). I certainly would like to get rid of the need for the tcp.smtp file entries, and this would do it. Instead of whitelisting though, I would expect to add the IP to the access-file. In my mind, an access-file entry would whitelist (as well as allowing relay), but a whitelist entry would not allow relay (as it does now). When I have a user who travels around with his laptop and needs to send email through my server to remote recipients, I ask him to authenticate. That bypasses the spam filters and allows him to send to remote recipients (relaying). In the absence of spamdyke, I would need a patched version of qmail. All users, traveling or local, typically authenticate (of course). I think that we all probably used a version of qmail with the smtp-auth patch before spamdyke 4.0 (and I'm guessing many if not most still do), but it would indeed be nice to be able to run qmail w/out the smtp-auth patch. In fact, I'd like the stock QMT to have spamdyke do authentication, as it's more flexible (can use different authentication mechanisms via simple configuration). A potential problem just occurred to me though. QMT uses the (preferred default) submission port 587, and includes a qmail-smtpd patch which forces authentication (export REQUIRE_AUTH=1). While spamdyke wouldn't typically be used on the submission port (since all connections must authenticate, the filters are pointless), I would still consider putting spamdyke in the submission pipe for a) authentication and b) logging capabilities. Spamdyke would need an smtp-auth-level=required option (or some such) in order to do this though. I haven't asked for this enhancement yet, have I? I guess I'm asking now. ;) When I have a legitimate sender who is trying to reach one of my users but is being blocked by a filter, I whitelist him. That bypasses all of the spam filters. Depending on how I whitelisted him, it may allow him to send to remote recipients. Ditto. Because I'm still using qmail to authenticate though, relaying is prohibited (with a global whitelist). Perhaps the last scenario is the problem you're describing -- if I add the sender to a global whitelist (e.g. not using a configuration directory), this sender can now use my server as a (nearly) open relay. If I added him by IP or rDNS, he could use any sender address he wanted (fully open relay). If I added him by sender address or sender domain, he could only relay if he used the whitelisted sender address. If I added him by sender address using a configuration directory so it only affects the recipient's domain, he can't relay at all. Bingo. :) I must admit that in an effort to KISS, I've avoided configuration directories up 'til now, and all my whitelisting has thus been host wide (not exactly global). I guess that could be considered a problem, except for a few considerations. First, I don't (as I assume you don't) just whitelist anyone who asks -- one of my users has to make the request. Then I ask the sender to fix the problem that caused the rejection. I often find that senders who are having trouble reaching my users are also having problems reaching lots of other people too -- i.e. they've been blacklisted somewhere or they have no rDNS. I do the same, and attempt to keep whitelisting at an absolute minimum. Second, I very rarely use the global whitelists. I prefer to whitelist a sender's domain within a configuration directory for the recipient's domain. That effectively allows anyone in the sender domain to send to anyone in the recipient domain. It prevents relaying and it also prevents them from spamming anyone else on the server (e.g. me). This is absolutely brilliant! By whitelisting only on a domain
[spamdyke-users] spamassassin not running with spamdyke's access-file
I've been testing spamdyke's auth capabilities a little, anticipating using it to enforce encrypted passwords (when that feature comes available). While doing so, I came across what I think is a bug. When the access-file parameter is specified: access-file=/etc/tcprules.d/tcp.smtp then my spamassassin doesn't scan. I believe this is because spamdyke is setting the RELAYCLIENT variable, which is what qmail's smtp-auth also does, causing spamassassin scanning to be bypassed. Here is the tail end of my tcp.smtp file (there are more addresses listed above): 192.223.243.129-140:allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/qmail-queue,NOP0FCHECK=1 :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan,DKSIGN=/var/qmail/control/domainkeys/%/private,NOP0FCHECK=1 BL, it appears that RELAYCLIENT is always being set when the access-file parameter is given. I believe it should only be set when a matching line in the tcp.smtp file contains the RELAYCLIENT variable (or when the client has authenticated). If this cannot be done in spamdyke, perhaps there's another way for simscan to control when spamassassin is invoked. I'd rather not go there though, as I'm anticipating using amavisd-new at some point. Thanks for your great work, Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] spamassassin not running with spamdyke's access-file
On 07/25/2012 10:13 AM, Sam Clippinger wrote: As for not setting the RELAYCLIENT variable unless the user authenticates, unfortunately that isn't possible: http://www.spamdyke.org/documentation/FAQ.html#SUGGESTION8 Isn't possible, or isn't easy to do? Please pardon my ignorance. In the case where spamdyke is handling authentication, why is it not possible to delay invoking qmail-smtpd until after authentication has taken place (or not)? The FAQ says: spamdyke must determine what environment variables to set before it starts the qmail-smtpd process (because after qmail-smtpd has been started, spamdyke can't change its environment). For that reason, spamdyke always sets the RELAYCLIENT environment if it has enough information to run its relaying filter. So I guess the key is what's considered to be enough information. In my mind, enough information would include whether the sender has authenticated or not. The FAQ continues: That way, qmail-smtpd will not prevent relaying if spamdyke determines it is allowed (e.g. because the connection is whitelisted). Does whitelisting take precedence over authentication? I don't think it should. Doing so would create an open relay for the whitelisted entry, which I think creates an unnecessary security hole. When I whitelist something, I only want to allow them to bypass the spam filters, not allow them to relay to domains outside of my host. No? BL, I think if spamdyke is going to handle authentication processing (and relay control) effectively, it's going to need to invoke qmail-smtpd only after authentication has occurrred (or not). Thanks for your patience with me on this, Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] reject-missing-sender-mx bug?
I can't reproduce this any more either. Chalk it up to a temporary DNS problem I guess. Thanks Sam. -- -Eric 'shubes' On 05/30/2012 08:40 AM, Sam Clippinger wrote: I can't reproduce this -- are you still getting this error? It's possible this was a temporary DNS resolution problem. -- Sam Clippinger On May 25, 2012, at 4:03 PM, Eric Shubert wrote: # spamdyke -v spamdyke 4.3.1+TLS+CONFIGTEST+DEBUG I (inadvertently) had reject-missing-sender-mx set in my spamdyke config. I received this message in the log: 05-25 00:13:56 spamdyke[13084]: DENIED_SENDER_NO_MX from: gndc-cose...@m.gmane.org to: cosedns-requ...@tagcose.com origin_ip: 80.91.229.10 origin_rdns: dough.gmane.org auth: (unknown) encryption: TLS reason: (empty) From the same host, I did this: # host m.gmane.org m.gmane.org is an alias for plane.gmane.org. plane.gmane.org has address 80.91.229.3 plane.gmane.org mail is handled by 10 plane.gmane.org. # Appears to be a bug? -- -Eric 'shubes' ___ 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] spamassassin not running with spamdyke's access-file
On 07/25/2012 12:28 PM, Sam Clippinger wrote: Well, enough information in this case refers to the options you're used in the configuration file. If spamdyke knows what domains it controls (local-domains-file or local-domains-entry) and knows the relaying rules (access-file), it has enough information to control relaying and it sets RELAYCLIENT. Changing a process' environment variables after the process has started is impossible. As for starting qmail-smtpd after authentication, I suppose nothing is absolutely impossible, but it would be difficult. Very difficult, given spamdyke's current code structure. In order to start qmail-smtpd after authentication, spamdyke would have to cache the entire SMTP conversation until that point, then start qmail-smtpd and replay it. That would mean spamdyke would have to fake two parts of the conversation: it would have to send its own greeting banner and it would have to send its own list of capabilities. The greeting banner isn't a big deal, it's almost always ignored by mail clients as long it contains at least some text. The capabilities list is important, however. That's how the server tells the client whether it supports authentication (and what protocols it uses), TLS, pipelining and other stuff. spamdyke wouldn't know what to say except for authentication and TLS, if they were configured. That would effectively remove features from the mail server, since clients wouldn't know they were supported. Also, if this delay is added for authentication, I think it should probably also be added for the other filters as well. For example, if the recipient address could possibly be whitelisted, spamdyke should delay starting qmail-smtpd until it knows for sure. If the address isn't on a whitelist, there's no point in setting RELAYCLIENT. (The same is true of the sender whitelist.) But that's even more problematic, because now spamdyke is caching a huge part of the SMTP conversation without knowing what qmail-smtpd's real responses will be. For example, if qmail-smtpd has been patched to do recipient validation or quota enforcement, spamdyke might accept a recipient address that qmail-smtpd will reject when the conversation is replayed. Then the client thinks the address was accepted but it wasn't -- what to do? One possible workaround would be to save the conversation AND run qmail-smtpd (as it does now). Then if authentication succeeds or a whitelist is triggered, spamdyke could kill qmail-smtpd, set the RELAYCLIENT variable, restart qmail-smtpd and replay the conversation up to that point. That is, unless qmail-smtpd has been patched to change its behavior after authentication, which means some of its responses might change. Caching conversations also gets tricky due to memory usage -- if spamdyke tries to use too much memory, the softlimit program (if in use) will cause it to malfunction. Even without softlimit, spamdyke needs to be very careful about its memory footprint (busy servers, lots of connections, limited RAM). The data can be cached to disk, but then there's a risk of stale cache files, running out of disk space and exposing sensitive information. spamdyke wasn't written with any of this in mind; it'd take a pretty big overhaul of the codebase. So it's difficult.:) Patching simscan is much easier. As for whitelisting vs. authentication, they're the same thing as far as spamdyke is concerned. Either one turns off all of spamdyke's filters and allows relaying. That's a holdover from the days before spamdyke supported authentication -- when I added the authentication code I just made it set the same flag as the whitelist code. FWIW, I disagree that whitelisting shouldn't allow relaying -- I often use it for exactly this purpose, especially when sending email from web servers. BTW, what does BL mean? -- Sam Clippinger I'm beginning to see the difficulties presented with spamdyke handling authentication. I'm going to have to disagree with you though regarding the nature of authentication and relaying vs. whitelisting. I don't believe they're naturally the same, although spamdyke treats them as such. In a traditional setup, the ability to relay (more appropriately termed submit IMO) is controlled by authentication and by IP address via tcpserver, and nothing else. Whitelisting has had no effect on relay. This seems to me to be adequate and appropriate. From what you describe, when spamdyke is configured with access-file, whatever whitelist entries exist (regardless of their type) now become able to submit to external domains (relay), making the host more of an open relay than I would like. While whitelisting is something that's to be discouraged, its use becomes significantly more dangerous when access-file is used, given that anyone who can can spoof any one of the whitelisted entries can also use the host as
Re: [spamdyke-users] DNS resolver and cache
On 07/13/2012 10:20 AM, BC wrote: Another one that is available to me as a port for FreeBSD. What do you like about it and did you use djbdns at any point and if so, what did you not like about it? On 7/13/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: FWIW, I use PowerDNS now. (pdns-recursor package for CentOS) I didn't use djbdns. I think djbdns was good in its day, but I like to use software that is supported by the distro upstream when possible. I think that PDNS is modern, well supported and has a strong user base. I think it's presently the best choice for DNS software. I can't think of any good reason to use djbdns any more. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DNS resolver and cache
On 07/16/2012 10:51 AM, Dossy Shiobara wrote: The #1 reason I still use djbdns: I don't have to watch the security advisory mailing lists like a hawk for yet another piece of software. On 7/16/12 12:45 PM, Eric Shubert wrote: I can't think of any good reason to use djbdns any more. Personally, I prefer to let the upstream developers and packagers worry about that. I try to avoid running anything that isn't kept track of with package management. To each his own. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Greylisting effectiveness?
On 07/12/2012 10:36 AM, Gary Gendel wrote: On 7/12/12 1:18 PM, BC wrote: On 7/12/2012 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: I use an internal caching DNS server as a DNS forwarder for spamdyke's dns requests. This way I only need to query outside once, and subsequent spam bursts from the same server are rejected by local lookups to the cache. This dramatically lowers my pound rate on the above servers and gets subsequent spam rejected very quickly. I used to use dnscache, but I'm currently testing unbound as a replacement. Is this to say that you used to use djbdns for your caching DNS server but you are going to something else? Yes. I'm playing with unbound www.unbound.net FWIW, I use PowerDNS now. (pdns-recursor package for CentOS) -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Graylist performance
I've wondered for some time about the effectiveness of graylisting, especially given the effectiveness of other spamdyke filters. I recall the saying: you can't manage what you can't measure. While we do have a script or two that report stats for various filters, a meaningful count of graylist effectiveness is difficult. The problem with measuring graylisting accurately lies with tying the DENIED_GRAYLISTED messages to subsequent ALLOWED messages. For each DENIED_GRAYLISTED message for which there is no subsequent ALLOWED message, the email blocked as spam and the graylisting filter was effective. Chalk one up for graylisting. For each DENIED_GRAYLISTED message, if there is a subsequent ALLOWED message, then the message was simply delayed and not blocked (and is not considered spam). It would be interesting to tally the min/max and mean/median average delays for this category as well, in order to have an idea of how severe the delays are. Looking at the log messages, I see from: (unknown) in some cases. I presume that this is the envelope sender, while the message/internal sender is used for the graylist entries. Thus it's not possible to reconstruct the graylist 'key' from the contents of the log message, so matching up subsequent ALLOWED messages is impossible. Or am I missing something? I think that the simplest way of matching up messages would be if the log messages contained the Message-ID field from the email headers. I checked the TODO.txt file, and Frank beat me to the request: Log the Message-ID field so a message can be tracked from delivery to disk. spamdyke will need to add the Message-ID field if needed. Credit goes to Frank SDI. So I'd like to add +1 for this enhancement. Without it, the effectiveness of graylisting cannot be accurately determined. As always, thanks to Sam for his great work on spamdyke. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamdyke and Postfix
Nice suggestions, Mark. Thanks. On 07/06/2012 12:36 PM, Mark Frater wrote: Lastly and perhaps less as important would be the sender verification process which is listed in the smtp RFC but which qmail has no standard ability to perform. Once again this is a standard feature available in postfix. Are you talking about smtp-auth capability here, or something else? Which RFC/feature? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamdyke and Postfix
I see: http://en.wikipedia.org/wiki/Callback_verification I agree with Gary on this. I think a SPF checker would be more useful. I know that's already on the list of enhancements. Thanks again. -- -Eric 'shubes' On 07/06/2012 02:33 PM, g...@genashor.com wrote: I used that for a bit and found that it wasn't very useful. There are a lot of false negatives and virtually all were rejected by another check. Today's spammers don't have troubles grabbing a real email address from their lists. I'd like to see some hard data that would show it beneficial. There is already a lot of DNS lookups per connection to add one with no benefit. I suppose it would reject backscatter spam but not much else. Gary -- Sent from my HP TouchPad On Jul 6, 2012 4:43 PM, Mark Frater m...@nexus.co.za wrote: Hi Eric, I'm talking about sender-verification also known as call-out verification. It can be used for smtp auth or incoming mail or both. This is where the mail server first verifies that the 'sender's address' actaully exists before delivering the message. It does this by connecting to the sender's MX and attempting to send a message to the sender but quitting before the data command. Usually done as follows: helo, mail from: , rcpt to: sender@domain, check reply, quit. If 250, sender is verified and the mail is allowed through (and generally the verification result will also be cached for a variable time so as not to be abused in floods etc). The reason why I said this feature is of less importance is because it does have the potential to be abused. Though it seems quite widely used these days. Regards, Mark On 06 Jul 2012, at 10:07 PM, Eric Shubert e...@shubes.net wrote: Nice suggestions, Mark. Thanks. On 07/06/2012 12:36 PM, Mark Frater wrote: Lastly and perhaps less as important would be the sender verification process which is listed in the smtp RFC but which qmail has no standard ability to perform. Once again this is a standard feature available in postfix. Are you talking about smtp-auth capability here, or something else? Which RFC/feature? -- -Eric 'shubes' ___ 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] Spamdyke not processing
On 06/04/2012 10:25 PM, DK wrote: Hi there, I run a qmailtoaster machine, and installed spamdyke through the qtp package. Everything seemed to be fine (no errors reported). But spamdyke doesn'tt seem to do anything. there are no spamdyke entries in the log files. My graylist directories are not being populated.( I had created the graylist sub directories). I double checked my run file (everythign seems to be there). Ideas? D Did you restart qmail? (service qmail restart) This needs to be done on initial install. Also, qtp-install-spamdyke needs to be run after the qmail-toaster package has been upgraded as well. This is only until we get spamdyke integrated properly. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamdyke on submission port for access control
On 05/02/2012 08:34 AM, Faris Raouf wrote: One of the vital features missing from Plesk is the ability to control who can use the hosting server’s authenticated smtp facilities. I must be missing something here. To begin with, I'm not familiar with Plesk (I use QMailToaster). It seems to me that authentication is what controls the submission port. In QMT, use of the submission port requires authentication. This capability is provided courtesy of Jean-Paul van de Plasse's REQUIRE_AUTH Patch. Does Plesk not have this capability? -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Request for enhancement
On 04/27/2012 10:54 AM, Gary Gendel wrote: Since spamdyke runs on an unmodified qmail setup, it seems that a good addition would early detection of non-existing users. This will fix the backscatter problem that is inherent with qmail by rejecting email before queuing rather than bouncing them. http://en.wikipedia.org/wiki/Backscatter_%28email%29 Gary The todo.txt file contains this item: Finish testing the recipient validation code and add it to the codebase. That seems to indicate that this feature is close to being a reality. In the meantime, you can consider using chkuser (http://www.interazioni.it/opensource/chkuser/). -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Correct way to disable a domain from using Spamdyke filtering
On 04/18/2012 10:39 AM, Shane Bywater wrote: Hi, I just want to thank Sam for the great piece of software he has provided with clearly written documentation and a helpful FAQ. Following such I was easily able to install Spamdyke on my new Centos 6.2 using Plesk 10.4.4 control panel server. What I am wanting to know is the correct way of disabling Spamdyke filtering for multiple domains on the server by listing them in the recipient-whitelist-file file? Or do you need to use configuration directories? Regards, Shane Bywater As in many things *nix, there's not necessarily a correct (or incorrect) way of doing this. I think the recipient-whitelist-file would be simplest. You could whitelist an entire domain with a single entry: @domain.com As the documentations says though: NOTE: Using these features is a bad idea! -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] smtp-auth-command not seen?
On 03/21/2012 08:29 PM, Sam Clippinger wrote: I would be interested to know if giving the access-file option fixes this problem, even when the file does not contain the RELAYCLIENT value for the matching IP. It shouldn't change anything, but it would be good to know. Yes, adding the option appears to fix it. I added: access-file=/etc/tcprules.d/tcp.smtp to the configuration, and it works now (relay allowed when authenticated), and there is no longer an ERROR message when I run --config-test. So what's the right thing to fix, the program or the documentation? ;) Thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] smtp-auth-command not seen?
On 03/20/2012 03:00 PM, Eric Shubert wrote: I did a little testing, and this appears to be just a bug in the config-test. With these settings, cram-md5 is not advertised, and authentication does work. After a little more testing, I discovered that qmail-smtpd (w/chkuser) is rejecting non-local emails, because it doesn't realize that the sender has authenticated. If I set the RELAYCLIENT variable in the tcp.smtp file (which would normally create an open relay), will spamdyke still honor the relay-level=normal (default) setting, and reject unauthenticated attempts to relay? I ask this because the documentation about spamdyke's access-file says this: Remote servers are allowed to relay if the environment variable RELAYCLIENT is set to any value. Most qmail guides recommend an entry like this one: 11.22.33.44:allow,RELAYCLIENT= and it's not clear to me if spamdyke would see this variable set by tcp.smtp and allow access based on this. As always, thanks Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] smtp-auth-command not seen?
Yes, this is the same setup. Here are my configuration settings: dns-blacklist-entry=zen.spamhaus.org dns-blacklist-entry=bl.spamcop.net graylist-dir=/var/spamdyke/graylist graylist-level=always graylist-max-secs=2678400 graylist-min-secs=180 greeting-delay-secs=5 idle-timeout-secs=180 ip-blacklist-file=/etc/spamdyke/blacklist_ip ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords ip-whitelist-file=/etc/spamdyke/whitelist_ip local-domains-file=/var/qmail/control/rcpthosts log-level=info log-target=stderr max-recipients=15 rdns-blacklist-file=/etc/spamdyke/blacklist_rdns rdns-whitelist-file=/etc/spamdyke/whitelist_rdns recipient-blacklist-file=/etc/spamdyke/blacklist_recipients recipient-whitelist-file=/etc/spamdyke/whitelist_recipients reject-empty-rdns reject-ip-in-cc-rdns reject-unresolvable-rdns sender-blacklist-file=/etc/spamdyke/blacklist_senders sender-whitelist-file=/etc/spamdyke/whitelist_senders smtp-auth-command=/home/vpopmail/bin/vchkpw /bin/true smtp-auth-level=always tls-certificate-file=/var/qmail/control/servercert.pem tls-level=smtp As you can see, I do have local-domains-file, but I have not specified any access-file. Is the access-file required? I presumed not, as the doc says it may be given, and connections are allowed by default. When I tested authentication (using telnet), I got a Proceed message after authentication, so I presumed authentication worked ok and I didn't test any further (my bad). My qmail-smtpd is (still) patched with smtp-auth though, and it doesn't appear to recognize that authentication has taken place. I want to have spamdyke control authentication entirely, but it appears that spamdyke isn't setting RELAYCLIENT when authentication has taken place. I presume that spamdyke doesn't start qmail-smtpd until after authentication has taken place, otherwise RELAYCLIENT could not be set, right? Let me know if I can give you anything else to go on. Thanks Sam. -- -Eric 'shubes' On 03/21/2012 04:46 PM, Sam Clippinger wrote: Umm, no. If this is the same setup you described in your previous email (which I haven't had a chance to investigate yet, sorry), it looks like you're not supplying the local-domains-file or access-file options, so spamdyke doesn't have enough information to control relaying (i.e. it doesn't know which domains are local or who has permission to relay, so it has to trust qmail to control relaying). If those options are given, spamdyke will always set the RELAYCLIENT variable and control relaying itself. That will fix the problem: spamdyke will prevent relaying from non-authenticated senders and qmail-smtpd will accept non-local recipients passed by spamdyke. -- Sam Clippinger On Mar 21, 2012, at 5:49 PM, Eric Shubert wrote: On 03/20/2012 03:00 PM, Eric Shubert wrote: I did a little testing, and this appears to be just a bug in the config-test. With these settings, cram-md5 is not advertised, and authentication does work. After a little more testing, I discovered that qmail-smtpd (w/chkuser) is rejecting non-local emails, because it doesn't realize that the sender has authenticated. If I set the RELAYCLIENT variable in the tcp.smtp file (which would normally create an open relay), will spamdyke still honor the relay-level=normal (default) setting, and reject unauthenticated attempts to relay? I ask this because the documentation about spamdyke's access-file says this: Remote servers are allowed to relay if the environment variable RELAYCLIENT is set to any value. Most qmail guides recommend an entry like this one: 11.22.33.44:allow,RELAYCLIENT= and it's not clear to me if spamdyke would see this variable set by tcp.smtp and allow access based on this. As always, thanks Sam. -- -Eric 'shubes' ___ 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] Recipient blacklist vs. RDNS checks
Very nice explanation Sam. Thanks for all you do. -- -Eric 'shubes' On 02/14/2012 06:53 PM, Sam Clippinger wrote: Yes and no. From a purely academic standpoint, it takes less work/time for spamdyke to reject a blacklisted recipient than to perform the DNS tests because searching a file is faster than sending and receiving network data (assuming the file isn't huge). And yes, spamdyke re-reads all of its files (config files, whitelist, blacklist, graylist) for every incoming connection. Because the OS caches disk access, this doesn't incur much actual overhead. However, several factors make this a non-issue. First, your DNS server is caching the results for the frequent senders, so there's actually very little traffic being generated for those queries. Second, spamdyke runs its filters in a specific order (listed in the FAQ) in order to disqualify a connection as quickly as possible. This is because qmail must remain running as long as there is a chance the message will be accepted. As soon as spamdyke is sure the message will be rejected, it tells qmail to quit and continues talking to the remote server by itself. From a performance standpoint, closing the process and freeing the memory is a bigger win than the file/DNS comparison. Third, and most importantly, spamdyke is going to run the DNS queries whether you add the recipients to your blacklist or not. In order to try to reject a message as soon as possible, spamdyke runs its filters as soon as the required information is available: rDNS tests are run as soon as spamdyke starts, MX checks are run as soon as the sender is given, etc. However, even if those tests are positive, spamdyke refrains from sending a rejection until it's sure the message cannot possibly be accepted. For example, if you use a recipient whitelist, spamdyke can't reject a message until it sees the recipient address -- otherwise it might reject a message too early when the recipient is actually on the whitelist. The recipient is identified pretty late in the SMTP protocol, so spamdyke may have to hold its rejection for a while for safety. (In reality, a while is typically hundredths of a second.) So by the time the recipient address is given and spamdyke /could/ check the recipient blacklist, it's already done the DNS work. If the DNS tests triggered a filter, the recipient blacklist won't be checked at all. So there's really no point in using your spamdyke rejection messages to create a recipient blacklist -- it'll never be used anyway. Caveat: the third point above doesn't apply if configuration directories are in use. In that scenario, spamdyke doesn't run any tests until the recipient address is given, so it can first load the config files from the correct configuration directory(s). When that happens, the recipient blacklist is checked before the DNS tests are run. Overall, my advice is: don't worry about it. If your server is so heavily loaded that a few milliseconds of processing time are critical, you should upgrade the hardware or get a second server (or both). -- Sam Clippinger On Feb 14, 2012, at 4:58 PM, Angus McIntyre wrote: Watching the logs on my new mail server, I'm having the pleasure of seeing spamdyke knocking lots of incoming spam on the head. In most cases, the incoming messages are getting taken out by RBL_MATCH, SENDER_NO_MX or RDNS_MISSING rules. A lot of the messages would eventually fail anyway because they're being sent to non-existent recipients. My question is, should I bother adding those non-existent recipients to the recipient blacklist file? Does Spamdyke do less work/take less time to reject a message if it finds the recipient in a blacklist than if it has to do an RBL or RDNS check? I imagine that simple string-matching should be faster and more efficient than doing a network-check (RBL or RDNS), but it probably depends on the order in which Spamdyke does the checks, and whether it re-reads the blacklist file for each message it processes. Any recommendations? Angus ___ 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] Encryption policy enforcement
On 01/27/2012 04:38 PM, Sam Clippinger wrote: Interesting suggestions. The first one, logging how many users authenticate without TLS/SSL, is basically already there. Since the log messages already show both the authenticated user and the encryption status, you should be able to parse through them to find people who authenticated in the clear. That percentage is probably going to be pretty high, especially among Outlook users. I hadn't thought of that. You're right, it's in there. :) Outlook'03 doesn't support TLS, so I'm sure you're right there as well. Implementing a filter to require TLS for authentication shouldn't be too hard. Lots of servers already do this -- they either don't advertise authentication until after TLS starts OR only advertise challenge/response authentication until after TLS starts. spamdyke could do that too, as well as stripping out (and blocking) cleartext authentication offered by a patched qmail. I'd love to see this. It would certainly help to enforce a good security policy (no clear text passwords). Of course this would also require spamdyke to be installed on the submission port 587, but that's something I'd be willing to do if this option were available. Having spamdyke on port 587 will be needed also for some other future enhancements such as auto-whitelisting, so I don't think this is a big deal. Implementing a filter to require TLS for every connection could be problematic. Remote servers (as opposed to mail clients) wouldn't understand the problem and a lot of mail would bounce. Even if a remote server is capable of doing TLS for outbound connections (many aren't), convincing the admins of those remote servers to make the change would be a nightmare (to say the least). If always-on encryption is really what you want, why not just use SMTPS? This was somewhat of an afterthought. Enforcing this would indeed be a little impractical, but I'm a little surprised at how many servers are actually using TLS already (msn, gmail, as well as many small ones). Since the log messages have all the data required already to do analysis, this isn't a high priority. I just thought it might be a nice feature for companies who need a high degree of security. If the filter would be easy to code, I think it'd be a nice touch (not that it'd get much use). If the code would be troublesome, then forget it. Of course smtps (465) could be used internally, but there's no way to enforce an encryption policy externally (unless you write the filter). ;) Thanks again Sam for your great work with spamdyke. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] need to insert a special rule..
On 01/07/2012 07:39 AM, turgut kalfaoğlu wrote: For some reason, we have massive amounts of mail coming from facebook, to one local user. I am unable to stop it, because the From is different every time, there are hundreds of users in the To: header, and the local recipient is always one local poor guy. I'm good at C programming and I'd like to put something like if (strstr(sender,facebook) strstr(recipient,localsucker)) rejectmail++; into spamdyke.. I'd appreciate any *pointers where to place a such code and how it should read. Many thanks, -turgut Have you suggested that the local user change their notification preferences in facebook? When they're logged in, there's a drop down menu you can click in the top right corner. Select Account Settings, then click Notifications in the left column. This is where each user can control which emails are sent to them, and which are not. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] need to insert a special rule..
Too bad. I'm not suggesting you switch from plesk, but I use http://wiki.qmailtoaster.com which has eMPF built in, and is pretty simple to admin so long as you're comfortable with the CLI. -- -Eric 'shubes' On 01/07/2012 03:57 PM, turgut kalfaoglu wrote: Unfortunately my plesk-qmail does not seem to have that patch installed. It's a huge pain to recompile qmail with plesk's patches, plus the empf.. -t On 07.01.2012 18:02, Eric Shubert wrote: On 01/07/2012 07:39 AM, turgut kalfaoğlu wrote: For some reason, we have massive amounts of mail coming from facebook, to one local user. I am unable to stop it, because the From is different every time, there are hundreds of users in the To: header, and the local recipient is always one local poor guy. I'm good at C programming and I'd like to put something like if (strstr(sender,facebook)strstr(recipient,localsucker)) rejectmail++; into spamdyke.. I'd appreciate any *pointers where to place a such code and how it should read. Many thanks, -turgut Do you have the eMPF patch (http://www.inter7.com/?page=empf-install) applied to qmail? If you do, I believe that can be used to accomplish such a rule (and more). FWIW. ___ 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] junkemailfilter.com
Has anyone here used junkemailfilter.com's DNS blacklist or (more significantly) whitelist (http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists) in conjunction with spamdyke? Just wondering if it's compatible, given the multiple return statuses that junkemailfilter uses. If so, sample configuration file entries would be helpful. TIA. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] New version: spamdyke 4.2.1
On 01/04/2012 10:58 AM, Sam Clippinger wrote: Just when you thought it was safe to go back to your Inbox, spamdyke version 4.2.1 is now available: http://www.spamdyke.org/ This version extends the log messages to show why a blacklist is matched. It also fixes a few minor bugs. Version 4.x is NOT backwards compatible with 3.x; be sure to read the documentation before upgrading. Version 4.2.1 is backwards-compatible with version 4.2.0; simply replacing the old binary with the new one should be safe. -- Sam Clippinger Thanks for the updates, Sam. When I upgraded on my test machine (which is a bit of a mess at times), I noticed this when running tests: ERROR(graylist-level): Found domain directory for a domain that is not in the list of local domains; ... INFO(graylist-level): Local domain has no domain directory; ... The summary at the end says: SUCCESS: Tests complete. No errors detected. I'm wondering, shouldn't the first message (ERROR) be INFO instead, like the 2nd one? Thanks again. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] whitelist_senders file format
On 11/21/2011 04:23 AM, turgut kalfaoğlu wrote: Hi there. what is the correct format for the whitelist_senders file? I want to whitelist an entire domain with a borked DNS in the whitelist.. Do I do *@abc.com or just abc.com in this file? Thanks -t I use @abc.com -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Question about Greylisting and deleting Zero-Length-Entries
On 11/02/2011 03:11 AM, t...@uncon.org wrote: Quoting Eric Shuberte...@shubes.net: I've been wondering though about perhaps using tmpfs for the graylist tree. That might be a potential solution as well for hosts that process huge amounts of email. Of course the whole tree would be lost on rebooting, but if that was a problem it could be copied off periodically and restored. If I get some time one day, I may do some test comparisons. The thought of using up RAM for the graylist data doesn't fit well with me. I'd much rather have the RAM used as file cache, for both the mail itself, and for things like AV signatures. -trog Me too, but it depends on the amount. We're only talking inodes really. Might not take up all that much space. You're running a huge amount of messages though, so it might be a significant amount. Just a thought. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Long delay on connection (before SMTP prompt appear)
On 09/02/2011 11:34 AM, Marcin Orlowski wrote:
hi,
I got odd issue with one of my smtp box and I got some problems
finding the culprit out. The problem is that it takes
ages for smptd prompt to appear:
# telnet localhost 25
Trying 127.0.0.1...
[... wait, wait, wait ...]
Connected to localhost.
Escape character is '^]'.
220 Welcome to mail delivery server ESMTP
The wait time vary but is often 60+ secs, so MUA with default 60 secs
timeout complain.
All is started that way:
${TCPSERVER} -v -l ${HOSTNAME} -H -R -c 500 -u 1004 -g 1003 0 smtp
${SPAMDYKE} ${SMTPD} ${MYNAME} ${CHECKPASSSMTP} /bin/true 21 | cat
/dev/null
(Variables are fine), my name is `hostname` output and resolves both
ways. Sometimes (frequently enough to not ignore it) I also see
max number of instances of app invoked by tcpserver (usually
503) but at the same time the log does not indicate such
increase of traffic (usually there are 30-40). At the same time there's
said delay, launching ./qmail-smtp by hand shows no delay, so I suspect
tcpserver or spamdyke steps (or something they relay on). My first guess
was dns, but there's caching dns running locally plus I disabled
whatever I could to make tcpserver staying away from resolving anything.
Spamdyke config holds dns-level=none for the same purpose. Any ideas?
Regards,
I'd suspect DNS as well. Did you double check your /etc/resolv.conf
file, and be sure that dns requests are handled locally?
--
-Eric 'shubes'
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 100% CPU utilization and stuck spamdyke processes (4.2.0)
Is it spamdyke that's using the CPU, or another process? clamav had a problem doing this sort of thing a couple versions back (0.95.x iirc). Other than that, I haven't heard of anything like this. I'd look at processes related to queuing (scanners?) and see if there's a problem in that area. Given your volume, I'd suspect that there's a resource constraint that a little configuration tweaking might remedy. -- -Eric 'shubes' On 08/17/2011 10:33 PM, Chris Boulton wrote: We're seeing a lot of spamdyke processes on our servers getting stuck in some sort of state where they'll hang, and use 100% CPU until we kill -9 them. Anyone else seeing this with 4.2.0? From what it looks like, it occurs once spamdyke has done its job and Qmail has accepted the message. There'll always be open network descriptors stuck in CLOSE_WAIT: spamdyke 32096 root txt REG8,6 2752241731152 /usr/bin/spamdyke spamdyke 32096 root mem REG8,6 935041730437 /usr/lib/libz.so.1.2.3.3 spamdyke 32096 root mem REG8,6 14616 54944903 /lib/libdl-2.7.so http://libdl-2.7.so spamdyke 32096 root mem REG8,6 16671761733359 /usr/lib/libcrypto.so.0.9.8 spamdyke 32096 root mem REG8,6 1375536 54944893 /lib/libc-2.7.so http://libc-2.7.so spamdyke 32096 root mem REG8,6 3359361733360 /usr/lib/libssl.so.0.9.8 spamdyke 32096 root mem REG8,6 119288 54944779 /lib/ld-2.7.so http://ld-2.7.so spamdyke 32096 root0u IPv4 477462833 TCP [US]:smtp-[THEM]:62593 (CLOSE_WAIT) spamdyke 32096 root1u IPv4 477462833 TCP [US]:smtp-[THEM]:62593 (CLOSE_WAIT) spamdyke 32096 root2u IPv4 477462833 TCP [US]:smtp-[THEM]:62593 (CLOSE_WAIT) spamdyke 32096 root3u IPv4 477462971 UDP *:56058 spamdyke 32096 root4u unix 0x88005cac9500 477464597 socket spamdyke 32096 root5w FIFO0,8 477463023 pipe spamdyke 32096 root6r FIFO0,8 477463024 pipe An strace on the process shows that absolutely nothing is happening: $ strace -p 32096 Process 32096 attached - interrupt to quit ^CProcess 32096 detached Version: $ spamdyke -v spamdyke 4.2.0+TLS+CONFIGTEST+DEBUG (C)2011 Sam Clippinger, samc (at) silence (dot) org http://www.spamdyke.org/ We're receiving around 80,000 connections to spamdyke a day, and out of that end up with about 8 hung processes. I've just enabled the full-log-dir option in spamdyke to try and get some internal logs, but I can't leave it enabled for long due to the amount of mail we receive. Regards, Chris Boulton Lead Engineer BigCommerce Web: http://www.bigcommerce.com ___ 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] Problems with outgoing SPAM
Do you know for sure that they're coming from an external source? Could it be an infected machine that's sending them? In either case, I don't know of a way to throttle a user's activity. I would check the logs for the offending account(s), and change the password(s). Also, be sure that no passwords are ever sent in the clear. I wouldn't expect that fail2ban would be of much help, as there's no failure. I could be wrong about this though. I like the way that gmane.org handles this sort of thing. It throttles user submissions such that it only allows one message to be relayed every 5 minutes per account. It does accept them, but simply queues them up and sends them on at a slower pace. I'd like to see a patch to qmail-remote that would do such a thing, but I'm not aware of one. Wouldn't be too terribly difficult to code I would think. -- -Eric 'shubes' On 07/18/2011 07:32 PM, Carlos Herrera Polo wrote: fail2ban maybe ? With special rules I think it can help you 2011/7/18, BCbc...@purgatoire.org: Is this what the tar pit option in qmail is suppose to do? On 7/18/2011 11:00 AM, spamdyke-users-requ...@spamdyke.org wrote: I would like to know if spamdyke can block relay if the client is trying to send a lot of email in a small period of time or something else that can ease this problem. ___ ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Whitelists...
Putting your domain's addresses in whitelist_recipients pretty much defeats the purpose of spamdyke. Putting your domain's addresses in whitelist_senders would create a nearly open relay, allowing anyone to use your sever as a relay by simply knowing one of the addresses. Very bad idea. Something that's counter intuitive but very effective is to *blacklist* your local domain(s) in the blackist_senders file, as such: @mydomain.com Since all of your users authenticate (they do authenticate, don't they?), they pass through spamdyke (or better yet use port 587). Anyone attempting to spoof an address at your domain is blocked. This accomplishes what the reject-identical-sender-recipient is intended to remedy and then some, while still allowing users to send email to themselves (which I have a few who do - there's no good reason they shouldn't be able to). This works like a charm. -- -Eric 'shubes' On 06/13/2011 06:12 AM, ron wrote: That is kind of what I was seeing in the log files, once it hit the whitelist_recipients, then it seemed that the mail was accepted, even if it was spam. Not sure where I saw it at, but I remember reading about putting all recipients into that whitelist. On 6/13/2011 9:05 AM, Angus McIntyre wrote: ron wrote: Whats the consensus, good or bad idea to whitelist all email addresses within your company in spamdykes whitelist_recipients? Wouldn't that be rather counter-productive? If you whitelist all recipients at your company (and assuming that your mail server accepts mail only for people at your company) then you've essentially switched off spamdyke for all incoming mail. Or am I missing something? Whitelisting sender addresses at your company is also a poor idea, because spammers like to forge mail to make it appear to come from someone at the same domain. In other words, if the spammer's list includes 'f...@example.com' and 'bob-hcdggtzh8xnbdgjk7y7...@public.gmane.org', they'll often send mail to 'f...@example.com' with 'bob-hcdggtzh8xnbdgjk7y7...@public.gmane.org' in the 'From' line, and vice-versa. Angus ___ 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] Spamdyke ignoring my blacklists.
I would suspect that your spamdyke.conf file somehow isn't the one being used. Just a guess. What does your run file contain? On 06/13/2011 01:00 PM, li...@deltatechnicalservices.com wrote: In my /etc/spamdyke.conf I have these two lines... ip-blacklist-file=/etc/spamdyke.d/ip-blacklist.conf sender-blacklist-file=/etc/spamdyke.d/sender-blacklist.conf In the file /etc/spamdyke.d/ip-blacklist.conf I have this... 64.40.96.0/19 64.135.0.0/17 And as if that wasn't enough, I added to the /etc/spamdyke.d/sender-blacklist.conf news...@reply.newsmax.com mailto:news...@reply.newsmax.com news...@newsmax.com mailto:news...@newsmax.com The above should have stopped the message either by sender address or by IP address but.. NO, Spamdyke allows it. In my log spamdyke says this.. ( domain names of recipients changed to xxx for privacy reasons ) Jun 13 10:06:19 echo spamdyke[25509]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: j...@xx.com mailto:j...@xx.com origin_ip: 64.40.119.232 origin_rdns: mta232.reply.newsmax.com auth: (unknown) encryption: (none) Jun 13 10:24:05 echo spamdyke[32128]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: m...@xxx.net mailto:m...@xxx.net origin_ip: 64.40.120.201 origin_rdns: mta201c.reply.newsmax.com auth: (unknown) encryption: (none) Jun 13 11:40:51 echo spamdyke[30476]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: va...@.net mailto:va...@.net origin_ip: 64.40.119.236 origin_rdns: mta236.reply.newsmax.com auth: (unknown) encryption: (none) Jun 13 12:10:17 echo spamdyke[10883]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: l...@x.org mailto:l...@x.org origin_ip: 64.40.120.210 origin_rdns: mta210c.reply.newsmax.com auth: (unknown) encryption: (none) Jun 13 12:11:37 echo spamdyke[11302]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: c...@x.org mailto:c...@x.org origin_ip: 64.40.113.227 origin_rdns: mta227b.newsmax.com auth: (unknown) encryption: (none) Jun 13 12:11:46 echo spamdyke[11369]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: st...@.com mailto:st...@.com origin_ip: 64.40.120.207 origin_rdns: mta207c.reply.newsmax.com auth: (unknown) encryption: (none) Jun 13 12:13:05 echo spamdyke[12003]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: sa...@x.com mailto:sa...@x.com origin_ip: 64.40.120.208 origin_rdns: mta208c.reply.newsmax.com auth: (unknown) encryption: (none) Jun 13 12:20:16 echo spamdyke[16254]: ALLOWED from: news...@reply.newsmax.com mailto:news...@reply.newsmax.com to: m...@x.net mailto:m...@x.net origin_ip: 64.40.113.202 origin_rdns: mta202a.newsmax.com auth: (unknown) encryption: (none) ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamdyke ignoring my blacklists.
Bad guess. :(
Is there some (other) whitelist parameter that's being satisfied?
--
-Eric 'shubes'
On 06/13/2011 01:43 PM, Spamdyke User wrote:
service smtp
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
instances = UNLIMITED
env = SMTPAUTH=1
server = /var/qmail/bin/tcp-env
server_args = -Rt0 /usr/local/bin/spamdyke -f /etc/spamdyke.conf
/var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd
/var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw
/var/qmail/bin/true
}
On Mon, 13 Jun 2011 13:23:31 -0700, Eric Shubert wrote:
I would suspect that your spamdyke.conf file somehow isn't the one being
used. Just a guess. What does your run file contain?
___
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] Spamdyke ignoring my blacklists.
On 06/13/2011 04:12 PM, Spamdyke User wrote: There isn't much in the receivers whitelist but, since I have so little in these files, I will include them here... My entire spamdyke.conf was attached to a previous message so now you have it all except my version info which is spamdyke 4.2.0+TLS+CONFIGTEST+DEBUG receivers_whitelist.conf # # This is a list of our customers to exempt from spamdyke # postmaster@ abuse@ submission@ I don't think this form of wildcard is valid, at least I don't see it in the documentation. The only wildcard capability I see in the the documentation is for all addresses at a domain, such as @mydomain.com I would expect what you have to match nothing, but perhaps it's matching everything instead. Try using the full email address here. If you have more than one domain, include separate records for each domain. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
