Re: pre-queue spam check
On Sat, Apr 11, 2015 at 12:12:05PM +0200, Peter N. M. Hansteen wrote: Joerg Jung m...@umaxx.net writes: I also know about spamd, but that is not really an option for now as the server speaks v6 and STARTTLS, moreover I have legacy users which AUTH on port 25 as well. This does not play well with spamd. spamd doesn't even attempt smtp auth, but then once the sender is whitelisted (as a valid sender should be), the problem would go away. From my understanding, the user connects on port 25 (using STARTTLS and SMTP AUTH), is blocked by spamd (451 temporarily greylisted for 25 min), but usually MUAs try again some seconds later... so I do not see how these senders become valid and whitelisted? Besides, spamd does not (yet) support IPv6 or STARTTLS. Your regular and valid correspondents would not see spamd at all -- after all spamd is supposed to simply slow down the obvious spambots. In your scenario (as in most others) it's likely useful to explore the nospamd option, as in maintain a table of IP addresses or ranges that are simply never redirected to spamd. It's even in the spamd man page (first pf.conf ruleset example). With legacy users using SMTP AUTH I meant users from (global) dialup connections with (often) changing IP(v6) client addresses. I see no chance how I could whitelist them. Regards, Joerg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pre-queue spam check
On Sat, Apr 11, 2015 at 04:06:49PM +0100, Craig Skinner wrote: On 2015-04-11 Sat 16:04 PM |, Joerg Jung wrote: From my understanding, the user connects on port 25 (using STARTTLS and SMTP AUTH), is blocked by spamd (451 temporarily greylisted for 25 min), but usually MUAs try again some seconds later... Users connect to the submission port 587 via their MUAs. As I wrote earlier, in my (inherited) migration scenario some users still connect on port 25 via their MUAs. Otherwise, request them to upgrade their mail app to something that's less than 20 years old. Sure, that is what I'm currently working on and why I wrote *legacy* users. Unfortunately, in real world scenarios (with thousands of users) such migrations take a while, thus I need to provide the legacy access a little bit longer. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pre-queue spam check
Joerg Jung m...@umaxx.net writes: I also know about spamd, but that is not really an option for now as the server speaks v6 and STARTTLS, moreover I have legacy users which AUTH on port 25 as well. This does not play well with spamd. spamd doesn't even attempt smtp auth, but then once the sender is whitelisted (as a valid sender should be), the problem would go away. Your regular and valid correspondents would not see spamd at all -- after all spamd is supposed to simply slow down the obvious spambots. In your scenario (as in most others) it's likely useful to explore the nospamd option, as in maintain a table of IP addresses or ranges that are simply never redirected to spamd. It's even in the spamd man page (first pf.conf ruleset example). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pre-queue spam check
On 2015-04-11 Sat 16:04 PM |, Joerg Jung wrote: From my understanding, the user connects on port 25 (using STARTTLS and SMTP AUTH), is blocked by spamd (451 temporarily greylisted for 25 min), but usually MUAs try again some seconds later... Users connect to the submission port 587 via their MUAs. Otherwise, request them to upgrade their mail app to something that's less than 20 years old. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pre-queue spam check
On Wed, Apr 08, 2015 at 04:10:22PM +0200, Joerg Jung wrote:
The longer I think about it (while looking at the existing filter code), the
more I
come to the conclusion that I just should sit down tonight and write this
missing
SA filter. Based on the existing filters in -extras and the code from
http://www.benzedrine.ch/milter-spamd.html a SA filter should be
straightforward to implement.
So, unfortunately I had not much time tonight, hence I started with a
rather simple filter as finger exercise: a pause on connect, wait some
seconds before the initial 220. Idea borrowed from Sendmails
greet_pause feature [1] which I think is worthwhile to keep (some)
spammers away.
Diff below attached, slightly tested in a local filter chain setup. I do
not have a github account on purpose, so no pull request from me. Feel
free to commit the patch.
I will see if I find some time by the end of the week to write the
missing SpamAssassin and ClamAV filter.
Thanks,
Regards,
Joerg
[1] http://www.deer-run.com/~hal/sysadmin/greet_pause.html
diff --git a/extras/filters/Makefile b/extras/filters/Makefile
index c62a112..2b7698b 100644
--- a/extras/filters/Makefile
+++ b/extras/filters/Makefile
@@ -4,6 +4,7 @@ SUBDIR += filter-dkim-signer
SUBDIR += filter-dnsbl
#SUBDIR+= filter-lua
SUBDIR += filter-monkey
+SUBDIR += filter-pause
SUBDIR += filter-perl
SUBDIR += filter-python
SUBDIR += filter-stub
diff --git a/extras/filters/filter-pause/Makefile
b/extras/filters/filter-pause/Makefile
new file mode 100644
index 000..658cdb2
--- /dev/null
+++ b/extras/filters/filter-pause/Makefile
@@ -0,0 +1,4 @@
+PROG= filter-pause
+SRCS= filter_pause.c
+
+.include bsd.prog.mk
diff --git a/extras/filters/filter-pause/filter_pause.c
b/extras/filters/filter-pause/filter_pause.c
new file mode 100644
index 000..7f8a3f0
--- /dev/null
+++ b/extras/filters/filter-pause/filter_pause.c
@@ -0,0 +1,78 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2015 Joerg Jung j...@openbsd.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys/types.h
+
+#include inttypes.h
+#include stdio.h
+#include unistd.h
+
+#include smtpd-defines.h
+#include smtpd-api.h
+#include log.h
+
+static unsigned int pause_seconds = 5;
+
+static int
+pause_on_connect(uint64_t id, struct filter_connect *conn)
+{
+ unsigned int r;
+
+ log_debug(debug: filter-pause: sleeping %u, pause_seconds);
+
+ if ((r = sleep(pause_seconds)) != 0)
+ log_warnx(filter-pause: wakeup %u seconds too early, r);
+
+ return filter_api_accept(id);
+}
+
+int
+main(int argc, char **argv)
+{
+ int ch;
+ const char *errstr, *s = NULL;
+ log_init(-1);
+
+ while ((ch = getopt(argc, argv, s:)) != -1) {
+ switch (ch) {
+ case 's':
+ s = optarg;
+ break;
+ default:
+ log_warnx(warn: filter-pause: bad option);
+ return (1);
+ /* NOTREACHED */
+ }
+ }
+ argc -= optind;
+ argv += optind;
+
+ if (s) { /* RFC 5321 4.5.3.2 Initial 220 Message: 5 Minutes */
+ pause_seconds = strtonum(s, 1, 300, errstr);
+ if (errstr)
+ fatalx(filter-pause: seconds option is %s: %s,
errstr, s);
+ }
+
+ log_debug(debug: filter-pause: starting...);
+
+ filter_api_on_connect(pause_on_connect);
+ filter_api_loop();
+ log_debug(debug: filter-pause: exiting);
+
+ return (1);
+}
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: pre-queue spam check
On Wed, Apr 08, 2015 at 11:44:04AM +0200, Joerg Jung wrote: Hi, Hi, [...] I know about clamsmtp, spampd etc. which check/tag *after* queuing. But since I prefer not to annoy my users with quarantine (web-interfaces), ***SPAM*** subjects, spam folders, or similar things I want to ask: Is there any chance to filter/check for spam *before* queueing with opensmtpd? Well, one way would be to put spampd in front of OpenSMTPD and have it process all mail before passing it to the MTA. Side note: It looks like some lawyers say, once it is queued one is not allowed to delete (silently). Yes, the goal of opensmtpd is to take all necessary steps to ensure that mails don't get lost so once in queue, it HAS to be delivered somewhere, or a mailer daemon has to be generated. With my old milter setup (spam) mail is blocked by sendmail if spamassassin/clamav says so and *not* queued. Well, you could write a filter to reject the message if the body contains a header set by spamassassin/clamav and achieve the same. I do not need to stick with spamassassin, switching to dspam, mailscanner, rspamd, whatever would be okay, as long as I find an easy way to scan before queueing. In fact I played with dspam as it does not rely on additional daemons like clamsmtp and spampd and can speak LMTP directly with opensmtpd (while also calling clamav on its own). Thus this would really simplify the setup. But for the queueing I need something like: accept from any for domain domains virtual users no queue relay via lmtp://127.0.0.1:2525 while returning the error code of LMTP session back to sender... I guess this is not possible? Side question: it is not possible to relay via LMTP to local unix domain socket instead of IP socket, right? e.g.: ... relay via lmtp:///var/dspam/dspam.sock only when using deliver to lmtp (see man smtpd.conf) I know about opensmtpd-extras and have seen the filters, but these are not yet enabled and ready for production, right? Writing my own filter to check spam (similar as milter does) seems to be possible and I think I have the C skills to handle this. But since this is a production server I need something stable, e.g. can not rewrite the filter every n months to adjust the needs for the (not yet enabled) unstable API. true I also know about spamd, but that is not really an option for now as the server speaks v6 and STARTTLS, moreover I have legacy users which AUTH on port 25 as well. This does not play well with spamd. I also scan outgoing mails, as I really do not trust the users. Any hints and insights are welcome, maybe someone has a similar setup? I don't ;-) -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
pre-queue spam check
Hi, I'm in the middle of migrating a rather large existing openbsd setup with sendmail+milter, spamassassin, clamav, and dovecot as well as virtual users to a similar opensmtpd setup. Now I stuck a bit with the spam/virus checking. I know about clamsmtp, spampd etc. which check/tag *after* queuing. But since I prefer not to annoy my users with quarantine (web-interfaces), ***SPAM*** subjects, spam folders, or similar things I want to ask: Is there any chance to filter/check for spam *before* queueing with opensmtpd? Side note: It looks like some lawyers say, once it is queued one is not allowed to delete (silently). With my old milter setup (spam) mail is blocked by sendmail if spamassassin/clamav says so and *not* queued. I do not need to stick with spamassassin, switching to dspam, mailscanner, rspamd, whatever would be okay, as long as I find an easy way to scan before queueing. In fact I played with dspam as it does not rely on additional daemons like clamsmtp and spampd and can speak LMTP directly with opensmtpd (while also calling clamav on its own). Thus this would really simplify the setup. But for the queueing I need something like: accept from any for domain domains virtual users no queue relay via lmtp://127.0.0.1:2525 while returning the error code of LMTP session back to sender... I guess this is not possible? Side question: it is not possible to relay via LMTP to local unix domain socket instead of IP socket, right? e.g.: ... relay via lmtp:///var/dspam/dspam.sock I know about opensmtpd-extras and have seen the filters, but these are not yet enabled and ready for production, right? Writing my own filter to check spam (similar as milter does) seems to be possible and I think I have the C skills to handle this. But since this is a production server I need something stable, e.g. can not rewrite the filter every n months to adjust the needs for the (not yet enabled) unstable API. I also know about spamd, but that is not really an option for now as the server speaks v6 and STARTTLS, moreover I have legacy users which AUTH on port 25 as well. This does not play well with spamd. I also scan outgoing mails, as I really do not trust the users. Any hints and insights are welcome, maybe someone has a similar setup? Thanks, Regards, Joerg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
