The timing in those log messages looks very suspicious to me -- it looks like
the error occurs after exactly 5 minutes of inactivity. If spamdyke's timeout
features are disabled, there must be some other link in your setup enforcing a
5 minute timeout. Just spitballing here, maybe it's a firew
I'm sure this has been discussed before, but I don't think spamdyke will block
empty senders (I haven't dug through the code to verify this though). Empty
sender addresses are used by many mail servers to send bounce messages;
blocking them would likely have some bad side effects.
For what you
Unfortunately there's no option to hide the RBL name, but you could update the
code to hide it. The log message is generated by filter.c on line 1692. If
you change the 7th parameter to set_rejection() from this:
(tmp_buf[0] != '\0') ? tmp_buf : name_array[rbl_index]
to:
NULL
Th
The configure script is trying to find the library that contains
SSL_library_init() so it'll know what flags to use with gcc. It tries libssl
and libcrypto, but obviously that isn't working on your new OS. The source
code for the test program is in the config.log file along with the gcc comman
2.8M lines in 34 seconds? Yikes! Sounds like an infinite loop.
It's been a while since I've looked at that code (and I apologize I don't have
time to go through it in detail), but that error message is only printed from
one place in spamdyke's code. It runs when a TLS/SSL session is active an
H looks like a bug, but because spamdyke is compiled C, there's almost
no way to tell how it happened. If you updated your OS but didn't update
spamdyke, I'd suggest making sure you're on the latest version of spamdyke and
recompiling it on your updated OS. If you still see crashes, th
Yikes! I don't think that's going to be possible. spamdyke was written
specifically for qmail and makes a lot of assumptions about how qmail works.
For example, the way it controls relaying is by setting an environment variable
that qmail checks, tt reads lots of files from /var/qmail that mu
.
> Spamassassin offers this already with its `dns_options rotate` option.
> Distributing load between name servers helps them stay within the limits of
> DNSBL query limits, (i.e., URIBL_BLOCKED).
>
> Quinn
>
>
> On 13 Mar 2019 13:52:11, Sam Clippinger via spamdyke-users wr
Sorry, I missed your earlier email. I'll try to answer both questions here.
Unless you're setting spamdyke's dns-level option, it should be using the
primary servers in order, followed by the secondary servers in order, every
time it runs. If you're just setting the three DNS servers and not u
I have no idea -- I've never used LibreSSL. As long as they've only updated
the internal library code and not changed the API, it'll probably work fine.
-- Sam Clippinger
On May 26, 2018, at 2:42 PM, BC via spamdyke-users
wrote:
>
> Will spamdyke compile with TLS using the LibreSSL libra
Yes and no -- comment delimiters are only allowed at the start of a line, not
in the middle (allowing mid-line comments would have required making the config
file parser much smarter). However, because the parser is expecting to find an
IP address on each line and the line begins with an IP add
Unfortunately no, spamdyke can't block messages based only on the username. It
has a wildcard format to block any username at a given domain name but no
wildcard to block a given username at any domain.
However, if the sender also puts the username in the "From" line of the
message, the header
Keep in mind that "Received" lines are written in reverse order, so the top
line always the newest. Also, "Received" lines are trivial to fake and
spammers often do insert fake lines to throw off scanners.
But assuming all the lines you sent are genuine, it looks like user 3048
invoked a qmail
Any message headers can be filtered. On my own server, most of my filters are
for "From" and "Subject", but one very persistent spammer recently forced me to
add a "To" filter as well. I try to add as few header filters as possible, but
it just depends what the incoming spam looks like.
-- Sa
That's very unusual, it sounds like a setting on their server. It's been a
long time, but I remember a setting on old sendmail servers that would send an
"advisory message" if an email had been sitting in the queue too long. It was
just a "by the way" notice (and it always confused every user
Unfortunately, there really isn't a more elegant way. You could either add
them to a recipient whitelist file, which would bypass all filters, or you
could use the addresses to create files in a config-dir folder to just turn off
graylisting for those addresses. But neither of those options wi
In the message headers you quoted, I think the trailing ">" after the domain
name is what's not matching. Try changing your header blacklist file to this:
From: *goldswatches.com*
Return-Path: *goldswatches.com*
IOW, just add an asterisk at the end of each pattern. That should do
That would be pretty challenging to add. spamdyke can already require the
sender address to match the domain of the authentication username
(reject-sender=authentication-domain-mismatch) but it doesn't read qmail's
"assign" file at all.
In the long term, the best way to add something like this
Ah, I should have asked. Yes, that option should work.
-- Sam Clippinger
On May 5, 2017, at 8:57 AM, Quinn Comendant via spamdyke-users
wrote:
> Update: I added `reject-sender=none` to /etc/spamdyke.conf and these errors
> started appearing in the log:
>
>2017-05-05 06:33:46.87356350
That should do it, assuming you also have a line in your main configuration
file that says:
config-dir=/var/qmail/spamdyke
However, from the rDNS name, it looks like that sender could come from a huge
list of IPs. You might consider turning off the filter for the domain instead,
like th
Nice spreadsheet! I don't have all the data you do, but just looking at my
mail logs going back 1 month (excluding mailing list traffic), I gathered these
reject/accept stats. I apologize if the formatting is messed up:
Count Percent
DENIED_RDNS_RESOLVE
PT TO: t...@test.com
> 554 Refused. Your IP address is listed in the RBL at cidr.bl
>
> < we need to close the connection in this moment (when we receive 554
> Refused) instead of waiting for DATA and then waiting the default timeout.
>
> Thanks for your time.
>
&
Unfortunately no, spamdyke isn't designed with the idea of different timeouts
for different reasons. It will always keep the connection open as long as
there is any chance the message could be allowed. For example, if your
configuration includes a recipient whitelist and the remote IP is black
I assume the users are seeing that error when they try to send emails, not when
they're trying to login or read messages? My first guess is that you haven't
whitelisted connections from localhost (127.0.0.1), so spamdyke is blocking
Horde's attempts to deliver messages. But that's just a guess
It looks like your /usr/local/psa/var/log/maillog file is just a symlink to
/var/log/maillog (not /var/log/messages). Are spamdyke's log messages
appearing there?
-- Sam Clippinger
On Mar 5, 2017, at 11:43 PM, turgut kalfaoğlu via spamdyke-users
wrote:
> Hi there.. I recently noticed in
I don't understand how you have your jails configured -- is qmail in a
different jail from spamdyke? I'm just wondering, if the message is
originating locally, why does spamdyke see the origin IP as 10.0.1.15 instead
of 127.0.0.1? And where is the message really coming from -- maybe a rogue
p
cd /path/to/src/spamdyke-5.0.1
patch -p0 <
/path/to/patch/spamdyke-5.0.2-beta1-reject_sender_not_local.patch
make
Then copy the new binary into place.
Thank you very much for reporting this!
-- Sam Clippinger
On Nov 4, 2016, at 7:24 AM, Sam Clippinger via spamdyke-user
gt;
> I noticed that rcpthosts and morercpthosts are not appearing in the "current
> config"
>
> Do you want to see the full-log ?
>
>
>
> - Original Message - From: "Sam Clippinger via spamdyke-users"
>
> To: "spamdyke
It sounds like "reject-sender" is the right option... if it's not working, I
would look at qmail's configuration. spamdyke uses qmail's rcpthosts and
morercpthosts files to decide what addresses are "local" -- is there a separate
copy of qmail for each server/jail with different configurations?
Looking at those log messages, I don't think TLS has anything to do with this.
spamdyke's log message shows "encryption: (none)", which means TLS is not in
use.
When spamdyke logs TIMEOUT, it means the remote server held the connection open
too long without sending any data at all. Usually th
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... ha
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 connection
spamdyke won't log the IP in its current version, but it wouldn't be hard to
add. If you want a quick'n'dirty solution right away, you can add it very
easily... just edit exec.c and change line 206 to this:
SPAMDYKE_LOG_VERBOSE(current_settings, LOG_VERBOSE_AUTH_FAILURE "%s
%s", usernam
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
On Jul 22, 2016, at 11:37 AM, Faris Raouf wrote:
> Hi Sam,
>
> I just had a chance to have a go with the tests, and just as you expec
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 menti
I'll get that added to the next release, thanks!
-- Sam Clippinger
On May 10, 2016, at 5:37 AM, Jonas Pasche via spamdyke-users
wrote:
> Hey there,
>
> while the configure script of the current version tells that it would be
> able to handle an installation prefix ...
>
> $ ./configure --
9:36 AM, Philip Rhoades wrote:
> Sam,
>
>
> On 2016-05-05 22:27, Sam Clippinger via spamdyke-users wrote:
>> Very impressive numbers, thanks for sharing those!
>
>
> No worries - I plan to keep it up so I can see if gradually improving the
> spamdyking has an
You're correct that those messages are related to limits, but not the ones
softlimit can set. Those messages are about "hard" limits, which are set using
the "ulimit" command. I'd guess either BSD has a default hard limit or
something on your system is setting them before spamdyke runs. Those
Right now, spamdyke has no support for IPv6 at all, so it can't understand that
nameserver line. However, the only consequence should be that error message --
it shouldn't have any trouble skipping that line and using the IPv4 nameserver.
-- Sam Clippinger
On May 4, 2016, at 2:54 PM, BC via
Very impressive numbers, thanks for sharing those! Out of curiosity, of the
messages that were delivered, how did you judge if they were spam?
It sounds like the problem is that spamdyke-qrv is accepting messages to
invalid addresses? You can try running spamdyke-qrv manually with the "-v"
fl
Assuming the "ALLOWED" log message you provided is accurate, it looks like the
problem is authentication -- all filters are disabled after authentication
succeeds. Your log message shows the same username in both the "from" and
"auth" fields, which makes me suspect either the user's password ha
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 deli
Actually, this is exactly the patch I've been working on (slowly). It turns
out vpopmail has a lot of strangenesses that I didn't completely cover in my
first release of spamdyke-qrv. I'm pretty sure the patch is ready, I just want
to see a successful run of the test scripts before I release i
> On 2015-06-21 04:57, Philip Rhoades via spamdyke-users wrote:
>> Sam,
>> On 2015-06-21 03:12, Sam Clippinger via spamdyke-users wrote:
>>> Regex support is on the (rather lengthy) to-do list, but frankly it's
>>> not a very high priority -- there's a lot of l
Unfortunately I haven't spent any time on either of those things yet. I've
spent a significant amount of time trying to get the recipient validation
feature working but kinda lost steam a month or two ago. I'm gonna get back on
the horse here soon.
Can I just say again for the record that I'm
telist-entry=list.dnswl.org
>
> header-blacklist-file=/var/qmail/spamdyke/header-blacklist
>
> reject-sender=no-mx
> reject-recipient=same-as-sender
>
> sender-whitelist-file=/var/qmail/spamdyke/sender-whitelist
> sender-blacklist-file=/var/qmail/spamdyke/sender-blackl
It's hard to say what the problem might be without more information. Could you
post your spamdyke config file? Also, if you use the full-log-dir option,
spamdyke will capture everything that happens into a log file for each
connection, which should show exactly what's going on.
-- Sam Clippin
gt; Paul
>
> 2015-10-03 1:05 GMT-03:00 Philip Rhoades via spamdyke-users
> :
> Sam,
>
>
> On 2015-10-02 23:47, Sam Clippinger via spamdyke-users wrote:
> I guess so, but remember the wildcarding uses globbing, not regexes.
> What I mean is: using "?*" is equi
wrote:
> On 2015-10-02 15:42, Philip Rhoades via spamdyke-users wrote:
>> Sam,
>> On 2015-09-26 01:12, Sam Clippinger via spamdyke-users wrote:
>>> The header blacklist file has a different format from the sender
>>> blacklist file, so just copying entries from one
sure the host you telnet from isn't blocked or whitelisted for some other
reason (most folks whitelist localhost, for example).
-- Sam Clippinger
On Sep 25, 2015, at 1:31 AM, Philip Rhoades via spamdyke-users
wrote:
> Sam,
>
>
> On 2015-09-15 07:27, Sam Clippinger via sp
, you've seen this in action -- the
sender's mail client gave your address as a recipient but didn't put your
address on the "To" line in the message header.
-- Sam Clippinger
On Sep 13, 2015, at 9:20 PM, Philip Rhoades via spamdyke-users
wrote:
> Sam,
>
I'm not entirely sure I understand your question... if the Reply-To address is
always the same, you should be able to block it using the header blacklist
filter. If you're wanting to compare the Reply-To address to the From address
or the sender address, spamdyke doesn't have that ability.
--
> head-stratcher. It's timing out so it looks like the pipe isn't connecting
> to checkpasswd-pam. I tried hard-coding the string that was sent (and works
> fine on external checkpasswd-pam tests) but it still times out. However,
> spamdyke's auth works fine which is
Pretty cool, thanks for reporting that!
At this point, spamdyke doesn't support hooking in external scripts during
processing. I very much want to make that happen however, since it would make
it possible to invoke SpamAssassin or ClamAV within the delivery process.
That's probably a couple o
What version of spamdyke are you using? I fixed a bug related to this in
5.0.1... that doesn't mean there isn't another bug, I just want to make sure
you're on that version before I spend time chasing a bug that's already fixed.
:)
If you are on 5.0.1, could you post your configuration file th
Yep, that sounds familiar. If you need more reasons, I've also been seeing the
"big DNS packet" problem on my own server (but haven't fixed it yet):
https://productforums.google.com/forum/#!msg/apps/mIGTQVZiFxo/ULesU7hOo6wJ
The patch is available here:
http://www.memoryhole.net/q
I think you can test it by using the openssl client from the command line:
openssl s_client -ssl3 -connect SERVERNAME:PORT
If it connects and you see "Protocol: SSLv3", it's not disabled. If you see
"sslv3 alert handshake failure" and it doesn't connect, you're done!
-- Sam Clippinger
They're just warnings that I'm not checking the return value of a call to
fscanf(). fscanf() reads data from a file into one or more variables; its
return value shows how many variables were assigned. In the case of those
lines, I'm using fscanf() to simply skip over any carriage return or new
That's good to know, thanks for posting that info. I'm always amazed to hear
people still use Solaris any more... I endured it a few years ago because ZFS
was worth the pain, but finally had to abandon it because it was impossible to
get security updates without an enterprise contract.
spamdyk
I agree. qmail is rejecting your recipient address because it's not a local
address and you don't have permission to relay. If you authenticate first,
qmail should accept the message.
-- Sam Clippinger
On Aug 9, 2015, at 11:42 AM, Galatis via spamdyke-users
wrote:
> Hi,
> You're Not try
Actually, spamdyke is correct -- that IP does not have a valid reverse DNS
name. When I look up 10.221.34.64.in-addr.arpa, no PTR records are returned,
only one CNAME record: mail.lassosoft.com. Queries for mail.lassosoft.com also
return no PTR records, only A records. This setup is not valid
It's very difficult to say without more information. If you're trying to block
whole TLDs, for example *.review, an entry like this in your
sender-blacklist-file should do the trick:
@review
In that file, starting a line with a dot is not a wildcard, so a line that only
contains ".revie
The Gmail servers are probably simply dropping the connection without politely
closing out the TLS protocol. When OpenSSL tries to end the connection using
the TLS protocol, it receives an end-of-file message instead. Since the email
message has already been accepted, it's really not a problem
spamdyke should already be blocking messages to recipients with no domain name
-- that particular feature is not configurable. But it doesn't check the "To"
line in the message headers by default. You should be able to block them using
the header blacklist filter, something like this:
It can do this in a limited fashion right now. If the improper To field is
always "To: %from_email" (or something from a known set of bad values), you
could use the header blacklist filter to block it. But at present, there's no
way to block a message with a missing header line.
-- Sam Clippi
This is correct, with one small addition -- the "MAIL first" message is not
coming from spamdyke. That message is being generated by qmail, which is why
spamdyke logs it with DENIED_OTHER.
If you want to figure out exactly what's going on, you could turn on spamdyke's
full logging to capture t
IMHO, everyone should delete the softlimit program from their servers
immediately. Not that I have a strong opinion on the matter or anything. :)
The softlimit program seems like a good idea -- set an upper limit on the
amount of RAM a program can use, to guard against memory leaks (but not buf
ode, qmail never sees the message).
-- Sam Clippinger
On Jun 19, 2015, at 9:09 PM, Philip Rhoades via spamdyke-users
wrote:
> Sam,
>
> See inline comments:
>
>
> On 2015-06-20 11:53, Sam Clippinger via spamdyke-users wrote:
>> You're correct spamdyke does not
You're correct spamdyke does not support regexes for any of its options, but
you can use a wildcard in a sender or recipient white/blacklist file to match
entire domains by prefixing the line with an @ symbol. For example:
@example.com
Full documentation here:
http://www.spamdyke
I'm not familiar with GreyLite at all, but "connection-time" means spamdyke
does its work while the message is still coming into your mail server -- while
the connection with the sending server is active. This is as opposed to
filtering messages in the mail queue, after the remote server is no
Yes, all of the rejection messages can be customized. Each message is
controlled by an option that begins with "rejection-text". For example, the
message you gave can be changed with the option "rejection-text-ip-in-cc-rdns".
The full list of rejection message options is here:
http://
At present, spamdyke does not log the HELO name and there's no easy way to
configure it to do so. I've been intending to make the logging more
configurable to allow admins to capture information like this (and also the
Subject or other headers) but haven't gotten it done yet. Hopefully I'll be
I don't believe there is a "best practice" location for any of spamdyke's
files. I see where the documentation mentions /var/tmp, but that's just an
example. On my own server, I keep everything under /usr/local/spamdyke, but
many others use /var/qmail/spamdyke or /home/vpopmail/spamdyke... it'
Anything's possible hard to say. Could you post your config file? Have
you tried running the config-test command?
-- Sam Clippinger
On May 19, 2015, at 12:49 AM, Les Fenison via spamdyke-users
wrote:
> I finally got around to installing version 5.0.1 and then with excitement I
> did
address does not exist.
>
> Sorry about confusing you in my previous message.
>
> --
> BR,
> Konstantin
>
> On 2015-05-01 11:27, Konstantin via spamdyke-users wrote:
>> Testing it now. It really seems like issue with forwards on vpopmail
>> aliased domains is fi
spamdyke lives!
spamdyke version 5.0.1 is now available:
http://www.spamdyke.org/
This version fixes a ton of bugs, including a number of access violations that
can lead to crashes. Most importantly, the recipient validation feature now
works correctly (and has been exhaustively tested
on
>> errors in logs anymore. So I assume that problem in my case is fixed.
>> The only one that bothers me now is that spamdyke-qrv fails to check
>> valid recipients for aliased domain forwards. So to make that work now
>> I have to create an additional duplicate forwards f
les.d/tcp.qmail-smtp.cdb -c 40 -u 201 -g 200 0.0.0.0 smtp spamdyke -f /etc/spamdyke/spamdyke.conf /var/qmail/bin/qmail-smtpd /var/vpopmail/bin/vchkpw /bin/trueLet me know if I can provide you something more relevant, Sam.-- BR,KonstantinOn 2015-04-09 20:27, Sam Clippinger via spamdyke-users wrote:I've
Yes you did and I'm sorry I didn't find a solution then. Having more available
time now, I'd like to take another shot.
Looking over the logs you sent me last year, I believe the crashes you were
seeing are different from the ones reported earlier this week. In the
spamdyke.conf file you sent
I'd guess openssl is complaining about not seeing STARTTLS in your server's
response because spamdyke is hiding qmail's STARTTLS offer after the EHLO
greeting. spamdyke is supposed to do that if the "tls-level" option is set to
"none". You can confirm this by telnetting to port 25 on your serv
IP subnets using
>>> config-dir=/etc/spamdyke/config.d
>>> mail spamdyke # cat /etc/spamdyke/config.d/_ip_/10/1
>>> reject-empty-rdns=0
>>> reject-sender=none
>>> And it doesn't seem working for me. Did I missed something?
>
> On 2015-04-07 18:06,
If spamdyke was compiled on this server, I doubt the problem is glibc... it's
more likely the messages are showing a location within glibc because the fault
occurs within a library function. From those log entries, I think the most
likely clues are the ones mentioning a double free or corrupt m
It's hard to say without more information. From what you've shown, it looks
like the reject-empty-dns and reject-sender filters should be deactivated for
any connections from 10.1.x.x. But if that's not working, could you post your
full config and some log messages? I'd also suggest running t
Funny you should send this right now -- I'm actually working on spamdyke-qrv at
this very moment. I strongly recommend you don't use spamdyke-qrv from
spamdyke 5.0.0 -- it doesn't handle forward addresses correctly and its
understanding of vpopmail has a lot of bugs. I've been putting in a lo
The error DENIED_RDNS_RESOLVE means spamdyke found an rDNS name, but the name
it found doesn't forward-resolve to an IP address (any IP address). So even
though compxroads.com has an IP, m1.compxroads.com does not, so spamdyke
rejected it.
-- Sam Clippinger
On Mar 24, 2015, at 4:03 PM, Den
DENIED_RDNS_RESOLVE is produced by the "reject-unresolvable-rdns" filter. If
you disable that option in your configuration file, that filter will stop
blocking connections.
http://spamdyke.org/documentation/README.html#RDNS
Enabling or disabling filters for specific servers, senders or
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
You're quite correct -- this is a bug in version 5.0.0. I've got it fixed in
the next version, hopefully to be released very soon.
-- Sam Clippinger
On Feb 2, 2015, at 1:38 PM, Heiko Bornholdt via spamdyke-users
wrote:
> Hi,
>
> I’m trying to replace my Spamdyke 4.3 with 5.0. I want to d
This is correct -- spamdyke-qrv has a bug that doesn't correctly validate
forward addresses that are not hosted locally. I hope to have a new version of
spamdyke available very soon that will fix this problem (and several others).
Just need to get all the test scripts to run successfully...
-
89 matches
Mail list logo
