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
spamdyke-users@spamdyke.org wrote:
Hi,
I’m trying to replace my Spamdyke
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...
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,
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
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
working for me. Did I missed something?
On 2015-04-07 18:06, Sam Clippinger via spamdyke-users wrote:
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
/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 been looking through the many log files you sent, thank for beingso
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
spamdyke-users@spamdyke.org wrote:
I finally got around to installing version 5.0.1 and
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
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:
the message).
-- Sam Clippinger
On Jun 19, 2015, at 9:09 PM, Philip Rhoades via spamdyke-users
spamdyke-users@spamdyke.org wrote:
Sam,
See inline comments:
On 2015-06-20 11:53, Sam Clippinger via spamdyke-users wrote:
You're correct spamdyke does not support regexes for any of its
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
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
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:
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
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:
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
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
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
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.
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
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:
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
spamdyke-users@spamdyke.org
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
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 how I discovered the above problem.
Gary
On 08/24/2015 12:26 PM, Sam Clippinger via spamdyke-users wrote:
What
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.
--
t; On 2015-09-14 11:38, Sam Clippinger via spamdyke-users wrote:
>> 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.
>
>
> Ah . . OK - I will
ers@spamdyke.org> 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 cop
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
<spamdyke-users@spamdyke.org> wrote:
> Sam,
>
>
> On 2015-09-15 07:27, S
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
ist.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-blacklist
>
> graylis
ine comments:
>
>
> 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
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
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
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
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.
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"
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
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,
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",
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
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
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...
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-users
<s
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
to have more
> information
>
> 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"
> <spamdyke-us
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
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
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
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
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
> RCPT 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
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.
--
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
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
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
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
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:
>
>
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
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
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
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
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
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
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,
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
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
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
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
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
71 matches
Mail list logo