Re: [spamdyke-users] Localhost relaying denied

[Faris Raouf via spamdyke-users]

Thanks Sam. I will investigate ASAP.

 

You're right that whitelisting and authentication have no effect on the
relay filter.  spamdyke allows relaying in three situations: when the
RELAYCLIENT environment variable is set, when /etc/tcp.smtp has a matching
rule that sets RELAYCLIENT or when a spamdyke option allows relaying.  So...
have you compared the /etc/tcp.smtp file on the two servers?  I'd bet
there's a line on the "can send" server that sets RELAYCLIENT for localhost
connections and the "can't send" server doesn't have it (note spamdyke does
not read this file itself; its CDB version is probably being read by
tcp-env).

 

It's been quite a while since I've worked with Plesk but I seem to remember
that option is set within the Plesk admin interface.  It'd be a good idea to
change it there -- otherwise if you change it on disk, it'll probably just
get overwritten the next time Plesk saves a change.


-- Sam Clippinger

 

 

 

 

On Oct 3, 2016, at 7:58 AM, Faris Raouf via spamdyke-users
<spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org> > wrote:





Dear all,

 

I'm absolutely confounded by a problem I'm having after upgrading five
systems from Spamdyke 4.3.1 to 5.0.1

 

On two of them, webmail (running locally, connecting from 127.0.0.1 to
127.0.0.1 port 25 via smtp, no authentication) works fine and can send
messages.

 

On the other three, spamdyke spits out a RELAYING_DENIED and blocks the
connection from 127.0.0.1 when trying to send messages.

 

--

Oct  3 12:07:38 hostnameredacted spamdyke[4927]: FILTER_RDNS_MISSING ip:
127.0.0.1


Oct  3 12:07:38 hostnameredacted spamdyke[4927]: FILTER_WHITELIST_IP ip:
127.0.0.1 file: /etc/spamdyke.d/whitelist_ip(6)


Oct  3 12:07:38 hostnameredacted spamdyke[4927]: FILTER_RELAYING


Oct  3 12:07:38 hostnameredacted spamdyke[4927]: DENIED_RELAYING from: (the
rest redacted)



 

 

All four systems use Plesk, which has 127.0.0.1 whitelisted for email - no
authentication is required for connections from that IP.

 

I have read the upgrade notes, which explain that IPs that are whitelisted
in the ip whitelist (or whatever) file are no longer automatically also
allowed to relay, and obviously that's at the heart of the problem in some
way.

 

What I cannot fathom is why two would work, and three would not. They are
all pretty much identical in every way that I can think of. Same Centos 6,
same versions of pretty much everything, very little differences anywhere.

 

None of them have any form of relay or smtp auth settings in spamdyke.conf.
All of them do have 127.0.0.1 whitelisted in the ip whitelist file - not
that it makes any difference in 5.0.1 of course.

 

Everything is controlled via smtp_psa file via xinetd

 

(stuff)

server  = /var/qmail/bin/tcp-env

server_args = -Rt0 /usr/local/bin/spamdyke -f
/etc/spamdyke.d/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

 

 

So, to resolve the problem, in theory all I have to do is add
ip-relay-entry=127.0.0.1 and indeed that does solve the problem.

 

I presume that's safe enough, given that we do want anything in localhost to
be able to send email without authenticating?

 

Is this a common setting?

 

But I feel I must get to the bottom of why some work, and some don't, out of
the box. It seems bonkers, and indicative of something else that might be
wrong.

None of the boxes are accidental open relays. Authentication is most
definitely required to send to non-local addresses. 

 

At one point I suspected it might have something to do with the webmail
configuration, but I can't find any differences at all. They are all set to
use smtp to connect to port 25 with no authentication.

 

 

In the hope that someone may spot an error in my config files, here is one
from a server where webmail can send, and another from a server where
webmail cannot send.

 

(--config-tests throws no errors on either of them)

(I do not know what I have qmail-rcpthosts / qmail-morescpthosts.cdb set but
they had been set when using 4.3.1 using the old syntax so I thought I'd
bring them over since I knew that configuration worked)

 

*

 

CAN SEND:

 

log-level=info

qmail-rcpthosts-file=/var/qmail/control/rcpthosts

 

max-recipients=5

idle-timeout-secs=60

greeting-delay-secs=11

 

ip-blacklist-file=/etc/spamdyke.d/blacklist_ip

sender-blacklist-file=/etc/spamdyke.d/blacklist_sender

rdns-blacklist-file=/etc/spamdyke.d/blacklist_rdns

recipient-blacklist-file=/etc/spamdyke.d/blacklist_recipient

 

ip-whitelist-file=/etc/spamdyke.d/whitelist_ip

rdns-whitelist-file=/etc/spamdyke.d/whitelist_rdns

recipient-whitelist-file=/etc/spamdyke.d/whitelist_recipient

sender-whitelist-file=/etc/spamdyke.d/whitelist_sender

 

tls-certificate-file=/var/qmail/control/servercert.pem

tls-leve

[spamdyke-users] Localhost relaying denied

[Faris Raouf via spamdyke-users]

Dear all,

 

I'm absolutely confounded by a problem I'm having after upgrading five
systems from Spamdyke 4.3.1 to 5.0.1

 

On two of them, webmail (running locally, connecting from 127.0.0.1 to
127.0.0.1 port 25 via smtp, no authentication) works fine and can send
messages.

 

On the other three, spamdyke spits out a RELAYING_DENIED and blocks the
connection from 127.0.0.1 when trying to send messages.

 

--

Oct  3 12:07:38 hostnameredacted spamdyke[4927]: FILTER_RDNS_MISSING ip:
127.0.0.1


Oct  3 12:07:38 hostnameredacted spamdyke[4927]: FILTER_WHITELIST_IP ip:
127.0.0.1 file: /etc/spamdyke.d/whitelist_ip(6)


Oct  3 12:07:38 hostnameredacted spamdyke[4927]: FILTER_RELAYING


Oct  3 12:07:38 hostnameredacted spamdyke[4927]: DENIED_RELAYING from: (the
rest redacted)



 

 

All four systems use Plesk, which has 127.0.0.1 whitelisted for email - no
authentication is required for connections from that IP.

 

I have read the upgrade notes, which explain that IPs that are whitelisted
in the ip whitelist (or whatever) file are no longer automatically also
allowed to relay, and obviously that's at the heart of the problem in some
way.

 

What I cannot fathom is why two would work, and three would not. They are
all pretty much identical in every way that I can think of. Same Centos 6,
same versions of pretty much everything, very little differences anywhere.

 

None of them have any form of relay or smtp auth settings in spamdyke.conf.
All of them do have 127.0.0.1 whitelisted in the ip whitelist file - not
that it makes any difference in 5.0.1 of course.

 

Everything is controlled via smtp_psa file via xinetd

 

(stuff)

server  = /var/qmail/bin/tcp-env

server_args = -Rt0 /usr/local/bin/spamdyke -f
/etc/spamdyke.d/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

 

 

So, to resolve the problem, in theory all I have to do is add
ip-relay-entry=127.0.0.1 and indeed that does solve the problem.

 

I presume that's safe enough, given that we do want anything in localhost to
be able to send email without authenticating?

 

Is this a common setting?

 

But I feel I must get to the bottom of why some work, and some don't, out of
the box. It seems bonkers, and indicative of something else that might be
wrong.

None of the boxes are accidental open relays. Authentication is most
definitely required to send to non-local addresses. 

 

At one point I suspected it might have something to do with the webmail
configuration, but I can't find any differences at all. They are all set to
use smtp to connect to port 25 with no authentication.

 

 

In the hope that someone may spot an error in my config files, here is one
from a server where webmail can send, and another from a server where
webmail cannot send.

 

(--config-tests throws no errors on either of them)

(I do not know what I have qmail-rcpthosts / qmail-morescpthosts.cdb set but
they had been set when using 4.3.1 using the old syntax so I thought I'd
bring them over since I knew that configuration worked)

 

*

 

CAN SEND:

 

log-level=info

qmail-rcpthosts-file=/var/qmail/control/rcpthosts

 

max-recipients=5

idle-timeout-secs=60

greeting-delay-secs=11

 

ip-blacklist-file=/etc/spamdyke.d/blacklist_ip

sender-blacklist-file=/etc/spamdyke.d/blacklist_sender

rdns-blacklist-file=/etc/spamdyke.d/blacklist_rdns

recipient-blacklist-file=/etc/spamdyke.d/blacklist_recipient

 

ip-whitelist-file=/etc/spamdyke.d/whitelist_ip

rdns-whitelist-file=/etc/spamdyke.d/whitelist_rdns

recipient-whitelist-file=/etc/spamdyke.d/whitelist_recipient

sender-whitelist-file=/etc/spamdyke.d/whitelist_sender

 

tls-certificate-file=/var/qmail/control/servercert.pem

tls-level=smtp

 

config-dir-search=all-recipient

config-dir=/etc/spamdyke.d/configdir

config-dir=/etc/spamdyke.d/individuals

config-dir=/var/qmail/conf.d

#configs in the above directories are recipient-based only and
enable/disable dns blacklists and reject-empty-rdns type things

 

dns-blacklist-entry=zen.spamhaus.org

dns-blacklist-entry=bl.spamcop.net

 

reject-empty-rdns

 

 

 

 



 

CANNOT SEND

 

log-level=verbose

qmail-rcpthosts-file=/var/qmail/control/rcpthosts

qmail-morercpthosts-cdb=/var/qmail/control/morercpthosts.cdb

#*** I have tried removing the above two lines - makes no difference to
webmail sending

 

 

max-recipients=5

idle-timeout-secs=60

greeting-delay-secs=6

 

ip-blacklist-file=/etc/spamdyke.d/blacklist_ip

sender-blacklist-file=/etc/spamdyke.d/blacklist_sender

rdns-blacklist-file=/etc/spamdyke.d/blacklist_rdns

recipient-blacklist-file=/etc/spamdyke.d/blacklist_recipient

 

ip-whitelist-file=/etc/spamdyke.d/whitelist_ip

rdns-whitelist-file=/etc/spamdyke.d/whitelist_rdns

recipient-whitelist-file=/etc/spamdyke.d/whitelist_recipient

Re: [spamdyke-users] spam with rDNS resolving to "localhost"

[Faris Raouf via spamdyke-users]

Thanks Sam and BC.

 

We aren't using reject-unresolvable-rdns on this particular system.

 

I wonder if that's what's different about this particular setup? We use it
on most (or even all .. not sure) our other systems.

 

I think I'll whitelist 127.0.0.1 and blacklist localhost then and see what
happens. 

 

Thanks again!

 

 

 

From: spamdyke-users [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf
Of Sam Clippinger via spamdyke-users
Sent: 10 August 2016 13:42
To: spamdyke users <spamdyke-users@spamdyke.org>
Subject: Re: [spamdyke-users] spam with rDNS resolving to "localhost"

 

Adding "localhost" to your rDNS blacklist should work exactly as you expect
-- *any* connection that resolves to "localhost" will be blocked.  To allow
connections from the real local host, you could either whitelist 127.0.0.1
or, if you wanted other filters to remain active for local connections, use
a config-dir to remove "localhost" from the blacklist for 127.0.0.1.

 

Incidentally, are you using the reject-unresolvable-rdns filter?  That
filter has a special exception for "localhost" to allow that name for
127.0.0.1 but block it for all other IPs.


-- Sam Clippinger

 

 

 

 

On Aug 9, 2016, at 5:02 AM, Faris Raouf via spamdyke-users
<spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org> > wrote:





Dear all,

 

We're having problems with spam being allowed in from IPs with rDNS
resolving to "localhost".

This gets past the reject-empty-rdns filter.

 

Initially I thought these IPs has no rDNS - using dnsstuff, I get no result
(normally meaning no rDNS). But using host or dig I see the IPs really do
reverse resolve to localhost.

 

**

Example log entry:

 

spamdyke[24468]: ALLOWED from: sqozt...@vnnic.net.vn
<mailto:sqozt...@vnnic.net.vn>  to: redac...@redacted.tld origin_ip:
113.168.188.219 origin_rdns: localhost auth: (unknown) encryption: (none)
reason: 250_ok_1470423419_qp_24501

 

 

***

Check rDNS:

 

# host 113.168.188.219

219.188.168.113.in-addr.arpa domain name pointer localhost.

 

 

# dig -x 113.168.188.219

 

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> -x 113.168.188.219

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15578

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;219.188.168.113.in-addr.arpa.  IN  PTR

 

;; ANSWER SECTION:

219.188.168.113.in-addr.arpa. 21599 IN  PTR localhost.

 

;; Query time: 325 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Aug  9 10:41:58 2016

;; MSG SIZE  rcvd: 69

 

***

 

 

Is figure that it is not safe to add "localhost" in our rdns blacklist file.
Wouldn't our real, local, localhost 127.0.0.1 potentially get blacklisted? 

 

Any suggestions as to what to do about this would be much appreciated!

 

Errmm.. in the back of my head there is a dim bell ringing about this issue
and so it might have been discussed before. Sorry if I'm asking something
that's already been covered at some point. Google hasn't helped in this
case.

 

 

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

[spamdyke-users] spam with rDNS resolving to "localhost"

[Faris Raouf via spamdyke-users]

Dear all,

 

We're having problems with spam being allowed in from IPs with rDNS
resolving to "localhost".

This gets past the reject-empty-rdns filter.

 

Initially I thought these IPs has no rDNS - using dnsstuff, I get no result
(normally meaning no rDNS). But using host or dig I see the IPs really do
reverse resolve to localhost.

 

**

Example log entry:

 

spamdyke[24468]: ALLOWED from: sqozt...@vnnic.net.vn to:
redac...@redacted.tld origin_ip: 113.168.188.219 origin_rdns: localhost
auth: (unknown) encryption: (none) reason: 250_ok_1470423419_qp_24501

 

 

***

Check rDNS:

 

# host 113.168.188.219

219.188.168.113.in-addr.arpa domain name pointer localhost.

 

 

# dig -x 113.168.188.219

 

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> -x 113.168.188.219

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15578

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

 

;; QUESTION SECTION:

;219.188.168.113.in-addr.arpa.  IN  PTR

 

;; ANSWER SECTION:

219.188.168.113.in-addr.arpa. 21599 IN  PTR localhost.

 

;; Query time: 325 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Aug  9 10:41:58 2016

;; MSG SIZE  rcvd: 69

 

***

 

 

Is figure that it is not safe to add "localhost" in our rdns blacklist file.
Wouldn't our real, local, localhost 127.0.0.1 potentially get blacklisted? 

 

Any suggestions as to what to do about this would be much appreciated!

 

Errmm.. in the back of my head there is a dim bell ringing about this issue
and so it might have been discussed before. Sorry if I'm asking something
that's already been covered at some point. Google hasn't helped in this
case.

 

 

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

Re: [spamdyke-users] can't block envelope sender

[Faris Raouf via spamdyke-users]

Yup! That would be great. I just think it would be useful to know it is
happening, and where to look, sort of thing.

 

From: spamdyke-users [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf
Of Sam Clippinger via spamdyke-users
Sent: 25 July 2016 14:50
To: spamdyke users 
Subject: Re: [spamdyke-users] can't block envelope sender

 

Could probably do that.  Or maybe print the matching file/line in the
"reason" field, the same way it already does for blacklist matches?


-- Sam Clippinger

 

 

 

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

Re: [spamdyke-users] can't block envelope sender

[Faris Raouf via spamdyke-users]

Hi Sam,

 

I just had a chance to have a go with the tests, and just as you expected it
was down to the rDNS of the sender being whitelisted. 

I don't know how many times I'd checked, and missed seeing it :)

 

Unfortunately I can't remember why I whitelisted it :( It belongs to an ESP.
If they are sending stuff that can't pass SD's filters, it doesn't belong in
anybody's mailbox. But obviously I needed to whitelist it for some reason at
some point. I will have to have a think about this.

 

But this situation inspires me to ask you to consider adding something to
the wishlist: 

 

When a messages is allowed to pass as a result of being whitelisted, could
there be an option to change the logging so that instead of just ALLOWED it
shows ALLOWED_WL_[type] or maybe WHITELIST_[type] or something along those
lines?

 

 

 

If you can login to ms2 at the command line, you could also try running
spamdyke by hand so you can see more verbose output without flooding your
logs. 

 

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

Re: [spamdyke-users] can't block envelope sender

[Faris Raouf via spamdyke-users]

Thanks Sam. That's brilliant and hugely helpful.

 

I'll try to do this this evening, and failing that over the weekend.

 

I will also check the whitelists again in case I missed something.

 

Yes, ms2 is the edge server and that's where the sender is backlisted,
although I've just added it to the ip147 one as well for good measure :)

 

 

 

From: spamdyke-users [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf
Of Sam Clippinger via spamdyke-users
Sent: 21 July 2016 14:14
To: spamdyke users 
Subject: Re: [spamdyke-users] can't block envelope sender

 

>From what I can see, spamdyke should be blocking those messages.  This could
be a bug, but first I'd suggest carefully checking your whitelists.  In
almost every case I've seen like this where a blacklist simply will not
work, it turns out to be a whitelist entry that's overriding it.  You
mentioned your email flows through several different servers before it
reaches the user's mailbox... from the message headers, it looks like ms2 is
your edge server, is that where the blacklist entry is set?

 

If you can login to ms2 at the command line, you could also try running
spamdyke by hand so you can see more verbose output without flooding your
logs.  You don't need to stop your mail server for this; it won't interfere
with any normal operations.  First, set an environment variable so spamdyke
will think it's getting a connection from a remote server:

  export TCPREMOTEIP=94.143.105.188

Next create a very small spamdyke config file (can be anywhere, doesn't have
to be in /etc) with two options:

  log-target=stderr

  log-level=excessive

Then find the command line spamdyke is started with (in your "run" file) and
run it the same way, but add another "-f" for the new config file AFTER your
real config file.  (If you're curious why, it's because config options are
applied in the order they are read.  We want to override those two options
for this run, so they need to be read last.)  For example, on my server I
would run this:

  spamdyke -f /etc/spamdyke.d/spamdyke.conf -f /tmp/testing.conf --
/var/qmail/bin/qmail-smtpd /home/vpopmail/bin/vchkpw /bin/true

You should see the SMTP greeting banner just like a mail client does
(possibly delayed a few seconds by spamdyke) plus debug messages that would
normally go in the logs.  Type in these SMTP commands to imitate a client
and test the blacklist:

  EHLO cloudtengroup1.mta.dotmailer.com
 

  MAIL FROM: >

  RCPT TO: >

At that point, you should see either a 250 response if the message is
accepted or a 500 response if it is blocked, plus tons of debugging output
from spamdyke to show what it's thinking.  You can type QUIT or ctrl-C to
exit.

 

Hopefully that'll show what's happening.  If you can't spot the issue or
have trouble deciphering the output, feel free to email it to me privately
and I'll take a look.





 

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

[spamdyke-users] can't block envelope sender

[Faris Raouf via spamdyke-users]

Dear all,

I'm having a bit of an issue trying to block messages based on the envelope
sender. Basically it doesn't seem to work at all, so I'm obviously doing
something wrong.

All the other types of blacklists and whitelists seem to work just fine.

I understand the difference between the "From" and the envelope sender, and
that TLS can be an issue.

But as far as I'm aware it is the envelope sender that I'm targeting, and in
this case my qmail installation doesn't support TLS so spamdyke is set to
handle the TLS and should be able to read the contents of the message.

I'm using SpamDyke 5.01

Please could someone kindly take a quick look at my log/config/header of an
example email, to see what I'm doing wrong?

In the example below, the envelope sender I'm trying to block has
(some-reference-or-other)@tooplemail.com as the envelope sender so I'm using
@tooplemail.com in my blacklist_sender file.


***

Maillog extract:

Jul 21 10:32:55 ms2 spamd[30006]: spamd: checking message
<2dqy.87yto274c.20160721093145...@tooplemail.com> for qscand:500

Jul 21 10:32:57 ms2 spamd[30006]: spamd: result: Y 4 -
BAYES_00,DIGEST_MULTIPLE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREE_QUOTE_INS
TANT,HTML_MESSAGE,PYZOR_CHECK,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_1
00,RAZOR2_CHECK,RCVD_IN_DNSWL_NONE,SPF_PASS
scantime=1.9,size=55241,user=qscand,uid=500,required_score=3.0,rhost=localho
st,raddr=127.0.0.1,rport=53794,mid=<2DQY.87YTO274C.20160721093145243@tooplem
ail.com>,bayes=0.00,autolearn=no

Jul 21 10:32:57 ms2 qmail-scanner-queue.pl: qmail-scanner[25272]:
Clear:RC:0(94.143.105.188):SA:1(4.3/3.0): 2.092064 55184
bo-3ueb-2dqy-yto27-c0...@tooplemail.com redac...@redacted.tld
Why_is_Toople.com_different_to_the_rest?
<2dqy.87yto274c.20160721093145...@tooplemail.com>
1469093575.25274-0.ms2.redac...@redacted.tld:3611
orig-ms2.redacted.tld146909357479725272:55184
1469093575.25274-1.ms2.redacted.tld:46150

Jul 21 10:32:57 ms2 spamdyke[25257]: ALLOWED from:
bo-3ueb-2dqy-yto27-c0...@tooplemail.com to: redac...@redacted.tld origin_ip:
94.143.105.188 origin_rdns: cloudtengroup1.mta.dotmailer.com auth: (unknown)
encryption: TLS reason: 250_ok_1469093577_qp_25272

**


**
Spamdyke config file:

log-level=verbose
idle-timeout-secs=60
greeting-delay-secs=11
policy-url=http://www.redacted.tld/email.html

graylist-dir=/var/qmail/graylist
graylist-level=none
graylist-min-secs=300
graylist-max-secs=1814400

ip-blacklist-file=/etc/spamdyke.d/blacklist_ip
sender-blacklist-file=/etc/spamdyke.d/blacklist_sender
rdns-blacklist-file=/etc/spamdyke.d/blacklist_rdns
recipient-blacklist-file=/etc/spamdyke.d/blacklist_recipient

ip-whitelist-file=/etc/spamdyke.d/whitelist_ip
rdns-whitelist-file=/etc/spamdyke.d/whitelist_rdns
recipient-whitelist-file=/etc/spamdyke.d/whitelist_recipient
sender-whitelist-file=/etc/spamdyke.d/whitelist_sender

tls-certificate-file=/ssl/c1org1516.pem
tls-level=smtp-no-passthrough

#(Blacklists redacted)

reject-empty-rdns

**



**

/etc/spamdyke.d/blacklist_sender contains:

@tooplemail.com

**



**
EXAMPLE EMAIL HEADER 
(Slightly complicated because it goes through two qmail-scanner/spamdyke
servers, 
ms2.redacted.tld and 147.redacted.tld,
each with different spamassassin configs (hence the odd subject
modification!), 
to get to the mailbox)


Received: (qmail 25508 invoked by uid 2523); 21 Jul 2016 10:33:11 +0100
X-Qmail-Scanner-Diagnostics: from ms2.redacted.tld by ip147.redacted.tld
(envelope-from , uid 2020) with
qmail-scanner-2.10st 
 (clamdscan: 0.99.2/21940. mhr: 1.0. spamassassin: 3.3.2. perlscan: 2.10st.

 Clear:RC:0(178.62.199.136):SA:1(3.6/3.0):. 
 Processed in 2.510301 secs); 21 Jul 2016 09:33:11 -
X-Spam-Status: Yes, hits=3.6 required=3.0
X-Spam-Level: +++
Received: from ms2.redacted.tld (redacted)
  by ip147.redacted.tld with SMTP; 21 Jul 2016 10:33:08 +0100
Received: (qmail 25293 invoked by uid 500); 21 Jul 2016 09:32:57 -
X-Qmail-Scanner-Diagnostics: from cloudtengroup1.mta.dotmailer.com by
ms2.redacted.tld (envelope-from ,
uid 496) with qmail-scanner-2.10st 
 (clamdscan: 0.99.2/21940. mhr: 1.0. spamassassin: 3.3.2. perlscan: 2.10st.

 Clear:RC:0(94.143.105.188):SA:1(4.3/3.0):. 
 Processed in 2.094403 secs); 21 Jul 2016 09:32:57 -
X-Qmail-Scanner-MOVED-X-Spam-Status: Yes, hits=4.3 required=3.0
X-Qmail-Scanner-MOVED-X-Spam-Level: 
Received: from cloudtengroup1.mta.dotmailer.com (94.143.105.188)
  by ms2.redacted.tld with SMTP; 21 Jul 2016 09:32:54 -
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim1024;
d=tooplemail.com;
 
h=From:To:Subject:MIME-Version:Content-Type:Date:List-Unsubscribe:Reply-To:M
essage-ID; i=daniel.clem...@tooplemail.com;
 bh=l80qAnWoe07RouX288jDc7eGwnI=;
 
b=eKFZ6Hdnf2Y6CSyjmyGiZVhZ0sLTRBhdvTW6lTPSBXcSi4sN1cOahISl7yHYH+6e3C5BVWZhZR
Ac
 

Re: [spamdyke-users] ip-in-rdns-keyword - are hyphens supported?

[Faris Raouf via spamdyke-users]

Aha! Thanks Gary. I'd missed the vital "the dots in the examples below can
be any single character" when reading this.

 

Thank you!

 

 

 

From: Gary Gendel [mailto:g...@genashor.com] 
Sent: 06 May 2016 16:24
To: Faris Raouf ; spamdyke users

Subject: Re: [spamdyke-users] ip-in-rdns-keyword - are hyphens supported?

 

Faris,

Looks like it does.  From the documentation in the section on Reverse DNS:

When matching an IP address in an rDNS name, spamdyke looks for the IP
address in many forms; for example, if the IP address is 11.22.33.44,
spamdyke will look for the following patterns in the rDNS name (the dots in
the examples below can be any single character): 

The phrase in the parenthesis implies that any non-digit character would be
treated as a period.

Gary

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

[spamdyke-users] Sensible greeting delay?

[Faris Raouf via spamdyke-users]

Dear all,

 

Recently I've noticed that massive numbers of (presumably botnet) senders
are blocked by the earlytalker filter when greeting-delay-secs=11 but only a
fraction as many if I set it to 10 or less. 

I'm guessing that the current main botnets are set to start talking after 10
seconds even if they get no initial reply.

 

Despite it working so well, I'm wondering if using a setting of 11 might be
a bit excessive. Has anybody had any false positives with this? Does anyone
else use a setting as high as 11? 

 

 

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

Re: [spamdyke-users] Help getting TLS to work please

[Faris Raouf via spamdyke-users]

> Behalf Of Alessio Cecchi via spamdyke-users
> Sent: 10 March 2016 08:00
> 
> Hi,
> 
> if you use spamdyke fixcrio is no more necessary.
> --

Ah, that's what I thought. The notes I have say that spamdyke takes care of
the bare LFs.

But because I could not remember if I added it to the tcpserver line for
some specific reason, or whether it was added by the installer, I was afraid
to remove it.

Thank you again.




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

Re: [spamdyke-users] Help getting TLS to work please

[Faris Raouf via spamdyke-users]

> From: spamdyke-users [mailto:spamdyke-users-boun...@spamdyke.org] On
> Behalf Of Alessio Cecchi via spamdyke-users
> For me works fine with:
> 
> tls-level=smtp-no-passthrough
> tls-certificate-file=/var/ssl/wildcard.pem
> 
> and in /var/ssl/wildcard.pem there is a chain like this:
> 
> CERTIFICATE
> PRIVATE-KEY
> 
> > openssl s_client -connect localhost:25 --starttls smtp
> 
> Try with "-starttls"
> 

Thank you for your suggestion. I really appreciate it.

But in the past hour I've just found the cause: fixcrio

In my smtp/run file I have:

tcpserver -DRUvX -c "$concurrency" -l "`head -1 /var/qmail/control/me`" -x
/etc/tcpcontrol/smtp.cdb 0 smtp fixcrio /usr/local/bin/spamdyke -f
/etc/spamdyke.d/spamdyke.conf /var/qmail/bin/qmail-smtpd

Why is fixiocr here? Well, either I had to add it to make spamdyke work with
this particular setup, or it was added by the particular install script I
used to install this particular qmail installation. I just don't remember.

Unfortunately, fixcrio from ucspi-tcp-0.88 breaks TLS completely
(unsurprisingly!). 

Luckily there is a patch to fixcrio that allows it to support TLS, as seen
here: http://www.mail-archive.com/qmail@id.wustl.edu/msg48044.html

And applying this makes everything work perfectly, just as it should have
done in the first place! Yay!

I will experiment with removing fixcrio later. For now I'm just really
pleased it all works correctly.

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

[spamdyke-users] Help getting TLS to work please

[Faris Raouf via spamdyke-users]

Dear all,

 

I'm stuck with a qmail installation that doesn't support TLS, so I'm trying
to get Spamdyke to deal with it on incoming connections.

 

Unfortunately I've not managed to get it to work - I get the following error
in the maillog when testing:

 

**

unable to start SSL/TLS connection: A protocol or library failure occurred,
error:1408A0BB:lib(20):func(138):reason(187)

**

 

My spamdyke.conf contains the following:

 

tls-certificate-file=/ssl/servercert.pem

tls-level=smtp-no-passthrough

#tls-cipher-list=ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:DES-CBC3-SHA

tls-dhparams-file=/ssl/dhparams.pem

 

I've tried with and without the tls-cipher-list line commented out (which
I'm not sure is in any way correct anyway - I was just trying to disable
SSLv2 and SSLv3) and similarly with and without the dhparams line commented
out.

 

I'm using the following to test:

 

openssl s_client -connect localhost:25 --starttls smtp 

which just gives me:

 

*

CONNECTED(0003)

140244663195464:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
alert decode error:s23_clnt.c:744:

---

no peer certificate available

---

No client certificate CA names sent

---

SSL handshake has read 188 bytes and written 282 bytes

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

**

 

(I've also tried specifying a protocol such as -tls1_2 but that doesn't make
any difference)

 

Spamdyke itself has TLS compiled: spamdyke 5.0.1+TLS+CONFIGTEST+DEBUG 

I did a fresh compile just to be sure. openssl and openssl-devel are
installed (latest versions).

 

The .pem appears to be valid, in as far as it is copied from a
qmail-with-tls server where it does work, and openssl verify says:

/ssl/servercert.pem: OU = Domain Control Validated, CN = *.REDACTED.TLD

error 20 at 0 depth lookup:unable to get local issuer certificate

 

I did initially have a permissions error on the .pem but that was giving me
"I/O error - unexpected EOF" type errors for the certificate in the logs,
but changing the perms resolved that one, thanks to a post by someone else
on the list a while ago.

 

Does anyone have any suggestions? Am I missing something obvious, as usual
:) ?

Any pointers or suggestions would be very much appreciated.

 

 

 

 

 

 

 

 

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

Re: [spamdyke-users] RBL DNS query numbers

[Faris Raouf via spamdyke-users]

Thanks Sam!

 

 

From: spamdyke-users [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf Of 
Sam Clippinger via spamdyke-users
Sent: 17 January 2016 19:49
To: spamdyke users 
Subject: Re: [spamdyke-users] RBL DNS query numbers

 

I think you're exactly right -- the filter was triggered once and no other DNS 
lookups were performed.  Then multiple recipients were given, so you're seeing 
a rejection line for each one.  If you want to be absolutely sure, you could 
enable the "full-log-dir" option to capture one of these deliveries -- that log 
will show all the DNS traffic and all of the SMTP traffic.


-- Sam Clippinger

 

 

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

Re: [spamdyke-users] Still using 4.3.1

[Faris Raouf via spamdyke-users]

Thanks Sam. That's put my mind at ease.

 

To my knowledge, there are no security issues in version 4.3.1.  I've since
fixed several bugs that can cause crashes, but nothing I can imagine could
be a security risk.

 

There have been recent bugs in OpenSSL and glibc; those libraries should
definitely be upgraded anyway.  spamdyke loads the libraries dynamically,
which means they aren't included in the spamdyke binary, so just upgrading
them should be enough -- the next time spamdyke starts (when the next remote
server connects) it'll load the new version(s).

 

If it's any consolation, spamdyke isn't vulnerable to the recent glibc
GHOST bug -- the last version to use the vulnerable gethostbyname()
function was 3.0.1, back in 2007.


-- Sam Clippinger

 

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

[spamdyke-users] Still using 4.3.1

[Faris Raouf via spamdyke-users]

Dear all,

 

Forgive me for asking this question - I'm not a coder.

 

I've noticed that a few systems I look after use Spamdyke 4.3.1, compiled
back in 2012 or 2013.

 

Are there any security issues with this version? 

 

Would any of the various vulnerabilities found in certain ancillary linux
packages over the past few years have any impact (i.e. I'm wondering if I
should recompile).

 

 

 

 

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