Re: [Mimedefang] MIMEDefang 2.55-BETA-2 is available
On Mon, 16 Jan 2006, [EMAIL PROTECTED] wrote: *** NOTE INCOMPATIBILITY *** filter_begin NOW TAKES ONE ARGUMENT, NOT ZERO. IF YOUR FILTER HAS A PROTOTYPE FOR filter_begin, YOU SHOULD FIX OR REMOVE THE PROTOTYPE There'd be nice to have an example here. Not knowing perl very much I would not understand Fix or remove the prototype without an example from your previous post on this. That means that in mimedefang-filter you have a sub function that looks like this: sub filter_begin() then you should change that to sub filter_begin($) or sub filter_begin I already know what this means. But it is only because I did read previous David's message. I'm just saying that this INCOMPATIBILITY note should be more verbose and give an example for those, who do not know perl very well and will not understand this. I'm not very good in english so I'm sorry if I said something wrong and I was not understandable. Regards Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... Winnie the Pooh ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.55-BETA-2 is available
Tomasz Ostrowski wrote: On Mon, 16 Jan 2006, [EMAIL PROTECTED] wrote: I already know what this means. But it is only because I did read previous David's message. I'm just saying that this INCOMPATIBILITY note should be more verbose and give an example for those, who do not know perl very well and will not understand this. I'm not very good in english so I'm sorry if I said something wrong and I was not understandable. Regards Tometzky I think you were quite clear in what you asked. It's just that some people don't know how to read :-) I wish I could communicate in other languages as well as you. Cheers Bill -- What's the difference between Linux and Windoze? Linux - Thousands of programmers are working *WITH*you. Windoze - Thousands of programmers are working *AGAINST* you. Web Site http://www.maidment.com.au ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Ok, some progress... I've installed the package, I'm running it currently.
Anyone have any comments on it?
Thanks,
-Philip
--- examples/init-script.in.bak 2005-10-14 10:16:27.0 -0600
+++ examples/init-script.in 2006-01-17 00:58:34.0 -0700
@@ -39,16 +39,19 @@ [EMAIL PROTECTED]@
# If you want to keep spool directories around if the filter fails,
# set the next one to yes
# KEEP_FAILED_DIRECTORIES=no
# yes turns on the multiplexor relay checking function
# MX_RELAY_CHECK=no
+# yes turns on the multiplexor helo checking function
+# MX_HELO_CHECK=no
+
# yes turns on the multiplexor sender checking function
# MX_SENDER_CHECK=no
# yes turns on the multiplexor recipient checking function
# MX_RECIPIENT_CHECK=no
# Set to yes if you want the multiplexor to log events to syslog
MX_LOG=yes
@@ -212,16 +215,17 @@ start_it() {
printf %-60s Starting $prog:
rm -f $SOCKET /dev/null 21
$PROGDIR/$prog -P $PID \
-m $MX_SOCKET \
`[ -n $SPOOLDIR] echo -z $SPOOLDIR` \
`[ -n $MX_USER ] echo -U $MX_USER` \
`[ -n $SYSLOG_FACILITY ] echo -S $SYSLOG_FACILITY` \
`[ $MX_RELAY_CHECK = yes ] echo -r` \
+ `[ $MX_HELO_CHECK = yes ] echo -H` \
`[ $MX_SENDER_CHECK = yes ] echo -s` \
`[ $MX_RECIPIENT_CHECK = yes ] echo -t` \
`[ $KEEP_FAILED_DIRECTORIES = yes ] echo -k` \
`[ $MD_EXTRA != ] echo $MD_EXTRA` \
`[ $ALLOW_NEW_CONNECTIONS_TO_QUEUE = yes ] echo -q` \
-p $SOCKET
RETVAL=$?
if [ $RETVAL = 0 ] ; then
--- mimedefang.h.bak 2005-02-08 09:04:39.0 -0700
+++ mimedefang.h 2006-01-17 02:05:15.0 -0700
@@ -22,19 +22,21 @@ extern void write_percent_encoded(unsign
extern int percent_encode(unsigned char *in, unsigned char *out, int outlen);
extern void percent_decode(unsigned char *buf);
extern int MXCheckFreeSlaves(char const *sockname);
extern int MXScanDir(char const *sockname, char const *dir);
extern int MXCommand(char const *sockname, char const *cmd, char *buf, int len);
extern int MXRelayOK(char const *sockname, char *msg,
char const *ip, char const *name);
+extern int MXHeloOK(char const *sockname, char *msg,
+ char const *helo, char const *ip, char const *name);
extern int MXSenderOK(char const *sockname, char *msg,
char const **sender_argv, char const *ip, char const *name,
- char const *helo, char const *dir, char const *qid);
+ char const *dir, char const *qid);
extern int MXRecipientOK(char const *sockname, char *msg,
char const **recip_argv,
char const *sender, char const *ip, char const *name,
char const *firstRecip, char const *helo,
char const *dir, char const *qid,
char const *rcpt_mailer, char const *rcpt_host,
char const *rcpt_addr);
--- mimedefang.pl.in.bak 2005-10-28 08:05:27.0 -0600
+++ mimedefang.pl.in 2006-01-17 02:06:59.0 -0700
@@ -5168,31 +5168,38 @@ sub do_main_loop () {
if ($_ =~ /^relayok (\S*)\s+(\S*)/) {
$ip = percent_decode($1);
$name = percent_decode($2);
relay_ok($ip, $name);
chdir($Features{'Path:SPOOLDIR'});
next;
}
- if ($_ =~ /^senderok (\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)/) {
+ if ($_ =~ /^helook (\S*)\s+(\S*)\s+(\S*)/) {
+ $ip = percent_decode($1);
+ $name = percent_decode($2);
+ $helo = percent_decode($3);
+ helo_ok($ip, $name, $helo);
+ chdir($Features{'Path:SPOOLDIR'});
+ next;
+ }
+ if ($_ =~ /^senderok (\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)/) {
$sender = percent_decode($1);
$ip = percent_decode($2);
$name = percent_decode($3);
- $helo = percent_decode($4);
- $CWD = percent_decode($5);
- $QueueID = percent_decode($6);
+ $CWD = percent_decode($4);
+ $QueueID = percent_decode($5);
$MsgID = $QueueID;
# Get ESMTP args
$_ =~ s/^senderok (\S*\s+){5}\S*\s*//;
@ESMTPArgs = map { percent_decode($_) } split(' ', $_);
chdir($CWD);
- sender_ok($sender, $ip, $name, $helo);
+ sender_ok($sender, $ip, $name);
chdir($Features{'Path:SPOOLDIR'});
next;
}
if ($_ =~ /^recipok (\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S+)\s+(\S+)\s+(\S+)/) {
my($rcpt_mailer, $rcpt_host, $rcpt_addr);
$recip = percent_decode($1);
$sender = percent_decode($2);
$ip = percent_decode($3);
@@ -6494,42 +6501,68 @@ sub relay_ok ($$) {
# Set up globals
$RelayAddr = $hostip;
$RelayHostname = $hostname;
my($ok, $msg, $code, $dsn, $delay) = filter_relay($hostip, $hostname);
send_filter_answer($ok, $msg, filter_relay, host $hostip ($hostname), $code, $dsn, $delay);
}
#***
+# %PROCEDURE: helo_ok
+# %ARGUMENTS:
+# ip -- IP address of relay host
+# name -- name of relay host
+# helo -- arg to SMTP HELO command
+# %RETURNS:
+# Nothing, but prints ok 1 if we accept connections from this host.
+# ok 0 if not.
Re: [Mimedefang] Adding filter_helo support
On Tue, Jan 17, 2006 at 02:15:25AM -0700, Philip Prindeville wrote:
Ok, some progress... I've installed the package, I'm running it currently.
Anyone have any comments on it?
Yes: why do you remove the HELO argument in filter_sender? This means
you're breaking compatibility for those who don't want to use filter_helo.
I don't think that change is necessary?
Also, your code assumes you cannot call smfi_setreply in the helo()
callback, but that assumption is wrong. At least, it is according to
the milter API documentation. It's probably very useful to set a reply
after HELO!
I wonder what the behaviour of your patch is when returning 421, other
4xx or 5xx error codes from HELO, to various other MTAs... have you tested
anything like that?
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Mimedefang errors: What might be the cause?
Quoting Gary Funck [EMAIL PROTECTED]: From cf/README: confQUEUE_LAQueueLA [varies] Load average at which queue-only function kicks in. Default values is (8 * numproc) where numproc is the number of processors online (if that can be determined). confREFUSE_LA RefuseLA[varies] Load average at which incoming SMTP connections are refused. Default values is (12 * numproc) where numproc is the number of processors online (if that can be determined). For dedicated mail servers, the value of RefuseLA should be **greater** than the value of QueueLA. [snip] Hence RefuseLA should be **lower** than QueueLA, the number of daemon children should probably be lower than the number of queue runnners (MaxChildren vs. MaxQueueChildren). On a dedicated mail server, you want to set QueueLA *higher* than RefuseLA - the other way around will cause your queue to explode when the load is high [snip] The default of QueueLA lower than RefuseLA only makes sense for a server that does other things besides mail [snip] So which is it?? RefuseLA QueueLA ?? or QueueLA RefuseLA ?? should it be greater/higher or lower ?? Meni ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] How to Stop 451 4.7.1 Please try again later
Hi I relatively new to using mimedefang. Im having a problem where for some reason mimedefang is failing and mail is rejected with a 451 4.7.1 Please try again later Im trying to get to the bottom of what the mimedefang problem is, but in the meantime I wanted to set it to just accept the mail if there is a problem (mimedefang is just first line of defence have another system which will hopefully catch and spam/virus mail) In sendmail.cf I have Xmimedefang, S=unix:/var/spool/MIMEDefang/mimedefang.sock, T=S:5m;R:5m I thought as I didn't have the F=T flag then mail should just be accepted if the filter fails? In my maillog I get these sorts of errors mimedefang[18858]: mfconnect: No Free Slaves sendmail[30482]: K0G2RMKQ030482: Milter: connect: host=a.b.c.d, addr=x.x.x.x, temp failing commands sendmail[30416]: k0G2RIoU030416: Milter: to=[EMAIL PROTECTED], reject=451 4.7.1 Please try again later Has anyone any tips? Im using Fedora Core 2 with mimedefang 2.53 Thanks Paul ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Philip Prindeville wrote: Hmmm... I'm looking at MXRelayOK, MXSenderOK, MXRecipientOK, etc. and wondering about why there's duplication of both passing the same arguments again (ip, name, helo, etc)... As well as duplicating the validation logic for arguments... Because the filter_relay, filter_sender and filter_recipient functions might happen in different Perl slaves, so you can't (easily) store state in your Perl filter. It's easy to store the state in C and just pass it in again each time. -- David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Philip Prindeville wrote: I was wondering about moving the: write_mx_command(data-cmdFD, 'E', (unsigned char *) data-heloArg); into the helo() function from envfrom() instead. Won't work; you don't have a queue-ID yet. -- David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Philip Prindeville wrote: Anyone have any comments on it? Looks OK except for one thing: You've removed the HELO argument from filter_sender. We need to restore that; lots of people rely on it. With that change, I will add the patch to the official release. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] 40K+ emails a day and choking
David, David F. Skoll wrote: Stephen Ford wrote: I'm running Solaris 9 on a dual processor 220R with 2 gigs of ram and the box is having trouble keeping up with spam!?!? I hate to say this, but switch from SPARC to a commodity Intel box. Intel and AMD chips far outperform SPARC for the kind of processing MIMEDefang/SpamAssassin do. Even a mid-range dual Xeon at 2.4GHz with a couple of gigs of RAM can handle 40K emails/day with ease. Are you aware of any relevant benchmarks in this area? N ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] 40K+ emails a day and choking
On Tue, 2006-01-17 at 14:48 +, Nik Clayton wrote: David, David F. Skoll wrote: Stephen Ford wrote: I'm running Solaris 9 on a dual processor 220R with 2 gigs of ram and the box is having trouble keeping up with spam!?!? I hate to say this, but switch from SPARC to a commodity Intel box. Intel and AMD chips far outperform SPARC for the kind of processing MIMEDefang/SpamAssassin do. Even a mid-range dual Xeon at 2.4GHz with a couple of gigs of RAM can handle 40K emails/day with ease. at my last company we did with 4 machines, 3Mil/Day Messages without any problem. The machines where HP DL360 2G Ram 1 CPU ;) Are you aware of any relevant benchmarks in this area? N ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang -- Michael Lang [EMAIL PROTECTED] pgpSyljeNxerz.pgp Description: PGP signature ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] 40K+ emails a day and choking
Nik Clayton wrote: I hate to say this, but switch from SPARC to a commodity Intel box. Intel and AMD chips far outperform SPARC for the kind of processing MIMEDefang/SpamAssassin do. Even a mid-range dual Xeon at 2.4GHz with a couple of gigs of RAM can handle 40K emails/day with ease. Are you aware of any relevant benchmarks in this area? I don't have actual benchmarks, but we've had a couple of CanIt customers who tried both and switched to Intel/AMD boxes. They cited better performance/price. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] 40K+ emails a day and choking
From: Michael Lang Sent: Tuesday, January 17, 2006 7:50 AM [...] at my last company we did with 4 machines, 3Mil/Day Messages without any problem. The machines where HP DL360 2G Ram 1 CPU ;) With Mimedefang and SA? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] 40K+ emails a day and choking
On Tue, 2006-01-17 at 08:20 -0800, Gary Funck wrote: From: Michael Lang Sent: Tuesday, January 17, 2006 7:50 AM [...] at my last company we did with 4 machines, 3Mil/Day Messages without any problem. The machines where HP DL360 2G Ram 1 CPU ;) With Mimedefang and SA? yes, complex filter (ldap lookups ...) and clamav and kaspersky ... ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang -- Michael Lang [EMAIL PROTECTED] pgpuoLfa9DNRl.pgp Description: PGP signature ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] 40K+ emails a day and choking
At work here at 180 I am handling 200K/day easily with a Dell 2650 w/ twin 2.8 Xeon, 4Gig Ram NFS mounted maildirs running SM, MD, SA Clamd. The only bottleneck is a 1999 vintage NetApp which is about to be replaced. LA ~1 most of the time except when the NetApp gets clogged G At 09:20 AM 1/17/2006, you wrote: From: Michael Lang Sent: Tuesday, January 17, 2006 7:50 AM [...] at my last company we did with 4 machines, 3Mil/Day Messages without any problem. The machines where HP DL360 2G Ram 1 CPU ;) With Mimedefang and SA? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang John Jaeger System Administrator OneEighty Communications (888) 342-5987 (406) 294-4034 Email: [EMAIL PROTECTED] Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken. - Unknown ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Anyone noticing...
I don't know if it's the same place, but I've got a bunch of these going back to Dec 20 (as far back as my logs go). [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I'm guessing the ret@ e-mail is a particular spam bot signature. Probably. However, blocking all mail from any ret@ is doomed to generate false positives. All of mine have been coming from the same netblock (morphed a couple of times). It's currently 216.22.47.0/24. Back in the middle of 2004, I ended up using a script to block packets in IPTables from selected networks which were persistently sending SPAM which SA scored 15+, but who didn't get the hint when everything got a 5.7.1 error. I was seeing 500+ per day on a site where the daily mail volume was 4000. Worse still, they retried after greylisting. While the sites they came from were visibly related, it was hard to provide any sort of program logic to match on the host name. Some examples below: 12.129.167.64 mx83b.e-shapeconnection.com. 12.129.167.66 mx83b.i-bewellconnection.com. 12.129.167.67 mx83b.i-playingallnite.com. 12.129.167.68 mx83b.mybewellnetwork.com. 12.129.167.69 mx83b.myshapenet.net. 12.129.167.70 mx83b.myshapestructure.com. 12.129.167.71 mx83b.ourbewellconnection.com. 12.129.167.74 mx83b.ourshapenexus.com. 12.129.167.76 mx83b.playingallnite.com. 12.129.167.80 mx84b.i-bewellhookup.com. 12.129.167.81 mx84b.bewellnet.net. 12.129.167.82 mx84b.yourbewellnet.net. 12.129.167.83 mx84b.ourbewellnet.net. 12.129.167.84 mx84b.i-bewellnet.net. 12.129.167.85 mx84b.bewellnexus.com. 12.129.167.86 mx84b.bewellstructure.com. 64.156.172.10 mx95.mytanningdays.com. 64.156.172.11 mx95.yourtanningdays.com. 64.156.172.12 mx95.myshoptobreathe.com. 64.156.172.13 mx95.yourshoptobreathe.com. 64.156.172.14 mx95.mybeingenergetic.com. 64.156.172.15 mx95.yourbeingenergetic.com. 64.156.172.16 mx96.weekendlifers.com. 64.156.172.17 mx96.myweekendlifers.com. 64.156.172.18 mx96.TanningTime.com. 64.156.172.19 mx96.tanninghour.com. 64.156.172.21 mx96.myshoptobe.com. 64.156.172.22 mx96.beinganimated.com. 64.156.172.23 mx96.mybeinganimated.com. 64.156.172.8 mx95.myweekendtolive.com. 64.156.172.9 mx95.yourweekendtolive.com. 65.216.114.10 mx91.yourfunkingdom.net. 65.216.114.100 out6.mydigitalknowshow.com. 65.216.114.101 out6.ipinpoint.info. 65.216.114.102 out6.myfultondirect.com. 65.216.114.105 out6.myjackpotgamingoffers.com. 65.216.114.107 out6.eusahealthyweb.com. 65.216.114.11 mx91.jackpotgamingoffers.com. 65.216.114.110 out6.myinternetgamingoffers.com. 65.216.114.113 out6.ibargaintimes.com. 65.216.114.114 out6.ivendarefinancial.com. 65.216.114.115 out6.yourclubofferstoday.com. 65.216.114.116 out6.yourusa-wellbeing.com. 65.216.114.117 out6.edealfinders.net. 65.216.114.118 out6.yourdigitalknowshow.com. 65.216.114.119 out6.yourpinpoint.info. 65.216.114.12 mx91.jackpotgamingdeals.com. 65.216.114.120 out6.yourfultondirect.com. 65.216.114.121 out6.yourmemberselect.com. 65.216.114.122 out6.yourblinkpayday.com. 65.216.114.123 out6.ejackpotgamingoffers.com. 65.216.114.124 out6.evacationsforus.com. 65.216.114.13 mx91.jackpotgamingbargains.com. 65.216.114.130 out7.mybargaintimes.com. 65.216.114.131 out7.ecasinoreport.net. 65.216.114.132 out7.mysport-times.com. 65.216.114.133 out7.mydeal-finders.net. 65.216.114.134 out7.mydigitalknowshow.com. 65.216.114.135 out7.ipinpoint.info. 65.216.114.138 out7.myblinkpayday.com. 65.216.114.14 mx91.jackpotcasinodeals.com. 65.216.114.142 out7.my-vacay.com. 65.216.114.143 out7.myclubofferstoday.com. 65.216.114.144 out7.myinternetgamingoffers.com. 65.216.114.146 out7.yourset-for-life.net. 65.216.114.147 out7.ibargaintimes.com. 65.216.114.148 out7.ivendarefinancial.com. 65.216.114.149 out7.yourclubofferstoday.com. 65.216.114.15 mx91.jackpotcasinobargains.com. 65.216.114.151 out7.edealfinders.net. 65.216.114.152 out7.yourdigitalknowshow.com. 65.216.114.153 out7.yourpinpoint.info. 65.216.114.154 out7.yourfultondirect.com. 65.216.114.155 out7.yourmemberselect.com. 65.216.114.156 out7.yourblinkpayday.com. 65.216.114.157 out7.ejackpotgamingoffers.com. 65.216.114.159 out7.yourusawellbeing.com. 65.216.114.16 mx92.jackpotcasinotoday.com. 65.216.114.17 mx92.jackpotcasinonow.com. 65.216.114.19 mx92.myjackpotgamingbargains.com. 65.216.114.20 mx92.yourjackpotgamingbargains.com. 65.216.114.21 mx92.ijackpotgamingbargains.com. 65.216.114.24 mx02.leedirect.net. 65.216.114.25 mx02.greaterfun.com. 65.216.114.26 mx02.gamingplayer.com. 65.216.114.27 mx02.ibargainday.net. 65.216.114.28 mx02.idealpursuit.net. 65.216.114.29 mx02.ijackpotjoy.net. 65.216.114.32 mx8.ivendarefinancial.com. 65.216.114.33 mx8.yourclubofferstoday.com. 65.216.114.34 mx8.yourusa-wellbeing.com. 65.216.114.35 mx8.edealfinders.net. 65.216.114.36 mx8.yourdigitalknowshow.com. 65.216.114.37 mx8.yourpinpoint.info. 65.216.114.42 mx03.mybigaward.com. 65.216.114.43 mx03.mybiggestprizes.com. 65.216.114.44 mx03.memberselects.com. 65.216.114.45 mx03.iwilliamsdirect.info. 65.216.114.46
RE: [Mimedefang] Anyone noticing...
On Tue, 2006-01-17 at 17:30 +, Paul Murphy wrote: For more background, search the mailing list archives for Blocking spam senders using IPTables?. Before I spend a lot of time searching... Did you post the script, or just notes on the idea? Thanks, Richard ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Jan Pieter Cornet wrote: On Tue, Jan 17, 2006 at 02:15:25AM -0700, Philip Prindeville wrote: Ok, some progress... I've installed the package, I'm running it currently. Anyone have any comments on it? Yes: why do you remove the HELO argument in filter_sender? This means you're breaking compatibility for those who don't want to use filter_helo. I don't think that change is necessary? It was previously passed in filter_sender() because it wasn't available earlier (since obviously there was no support for helos). This was a design short-coming. And it's an attempt to KISS, by dividing and conquering the problem... In any case, the variable continues to be present in $Helo. Also, your code assumes you cannot call smfi_setreply in the helo() callback, but that assumption is wrong. At least, it is according to the milter API documentation. It's probably very useful to set a reply after HELO! Oh, right. I pulled a lot of code from the MXRelayOK(), where it wasn't available... I'll rework that. Or if you have patches... ;-) I wonder what the behaviour of your patch is when returning 421, other 4xx or 5xx error codes from HELO, to various other MTAs... have you tested anything like that? Want to telnet to my server and check it out? -Philip ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Anyone noticing...
Richard Laager wrote: On Tue, 2006-01-17 at 17:30 +, Paul Murphy wrote: For more background, search the mailing list archives for Blocking spam senders using IPTables?. Before I spend a lot of time searching... Did you post the script, or just notes on the idea? Thanks, Richard I did something similar to this to reduce the spam (and load). Whenever I get a message I put the remote smtp server IP address in a sql table along with a timestamp, SA score, and counter. This lets me know what the SA average is for any host connecting. Now that I know what the averages are, I query this information during the filter_recipient function and bounce messages where we have at least 5 messages to average on, and where that average is higher than the spam threshold that is read out of our ldap directory for that user. So lets say that a user has the spam sensitivity set to high (5) and we have a zombie connect and pass 5 messages that average 7 points. On the 6th message the zombie will pass the mail from and rcpt to, then mimedefang finds that the average is higher than the users threshold and bounces the message. To keep the database cleaned up I delete all records that have not been updated for 24 hours every hour. This change basically limits zombies to 5 messages before they are rejected, which saves the system from running SA on messages that are almost certainly spam. I don't have exact numbers but the mail load on the system dropped significantly. I need to update my graphdefang config so that I know the exact statistics, but haven't got to it yet. The only drawback that I have found to this solution is users that forward all of their mail to our mail system. After the change several called and complained that the forwarding broke because the forwarded mail was mostly spam which caused the remote mta to get rejected. I told the users that the forwarded mail is mostly spam and that the provider forwarding the mail was indeed relaying spam. Every user had their issues resolved by either asking us to remove spam filtering from their account or asking the forwarding provider to filter messages for spam before they forward. The reason why I did it this way instead of iptables was because we need to be able to adjust the spam filtering on a per user bases. This is why we don't make any decisions on the message until after the rcpt to and ldap lookup. I also wanted to make sure that the support address always works because all of our bounce messages say to email support for help. This has worked very well for us since someone will run into a problem, then email support, which has spam filtering disabled (100 point threshold). When the helpdesk gets the message they simply look at the header which tells them exactly why the message was rejected and allows them to walk the user though how to fix it. If we had gone with iptables we wouldn't be able to leave our abuse, postmaster, and support addresses open, and users would be rejected without an error message explaining exactly what happened. Since rejected email only costs us one ldap and one sql lookup we will live with that since those things are really cheap compared to mimedefang and SA. Hope this helps someone. schu ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Philip Prindeville wrote: It was previously passed in filter_sender() because it wasn't available earlier (since obviously there was no support for helos). This was a design short-coming. And it's an attempt to KISS, by dividing and conquering the problem... But it breaks existing filters; we need the helo arg back. And there's a good reason to pass HELO in filter_sender (and filter_recipient, for that matter): You may WANT to defer your HELO processing until later. Our commercial products, for example, let individual recipients decide if they want to use various rules, which means we need to defer all processing until at least RCPT. In any case, the variable continues to be present in $Helo. Not in filter_sender if we use your patch, unless we parse the commands file manually. If you re-work your patch to leave filter_sender as it was, I will include it in the official release. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Anyone noticing...
Richard, Before I spend a lot of time searching... Did you post the script, or just notes on the idea? Notes on the idea - I have a working Perl script to do the iptables changes, and a couple of useful shell scripts to lookup addresses and match names, but having seen the post by Matthew, I'd be tempted to give this a try instead... Paul. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.371 / Virus Database: 267.14.17/229 - Release Date: 13/01/2006 ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Jan Pieter Cornet wrote:
Also, your code assumes you cannot call smfi_setreply in the helo()
callback, but that assumption is wrong. At least, it is according to
the milter API documentation. It's probably very useful to set a reply
after HELO!
Ok, here are part of the revised diffs to mimedefang.c:
***
*** 556,561
--- 559,595
data-heloArg = NULL;
}
data-heloArg = strdup_with_log(helohost);
+
+ if (doHeloCheck) {
+ char buf2[SMALLBUF];
+ int n = MXHeloOK(MultiplexorSocketName, buf2, data-hostip,
+ data-hostname, data-heloArg);
+ if (n == 0) {
+ set_dsn(ctx, buf2, 5);
+ /* We reject connections from this relay */
+ cleanup(ctx);
+ DEBUG_EXIT(helo, __LINE__, SMFIS_REJECT);
+ return SMFIS_REJECT;
+ }
+ if (n 0) {
+ set_dsn(ctx, buf2, 4);
+ cleanup(ctx);
+ DEBUG_EXIT(helo, __LINE__, SMFIS_TEMPFAIL);
+ return SMFIS_TEMPFAIL;
+ }
+ if (n == 2) {
+ set_dsn(ctx, buf2, 2);
+ cleanup(ctx);
+ return SMFIS_ACCEPT;
+ }
+ if (n == 3) {
+ set_dsn(ctx, buf2, 2);
+ cleanup(ctx);
+ return SMFIS_DISCARD;
+ }
+ }
+
+ DEBUG_EXIT(helo, __LINE__, SMFIS_CONTINUE);
return SMFIS_CONTINUE;
}
I'm wondering, however, if this is the correct handling... What about n
== 1?
Suggestion for the future... perhaps have an enum for these values
that's a little
more intuitive.
-Philip
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Philip Prindeville wrote: But it breaks existing filters; we need the helo arg back. And there's a good reason to pass HELO in filter_sender (and filter_recipient, for that matter): You may WANT to defer your HELO processing until later. Our commercial products, for example, let individual recipients decide if they want to use various rules, which means we need to defer all processing until at least RCPT. That's got to get hairy when you have multiple recipients specified. It's hairy, but manageable. Doing per-recipient content-filtering is a lot hairier and less managable; we have to use hacks like stream_by_domain or stream_by_recipient. Unfortunately, that's just how SMTP works. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
David F. Skoll wrote: But it breaks existing filters; we need the helo arg back. And there's a good reason to pass HELO in filter_sender (and filter_recipient, for that matter): You may WANT to defer your HELO processing until later. Our commercial products, for example, let individual recipients decide if they want to use various rules, which means we need to defer all processing until at least RCPT. That's got to get hairy when you have multiple recipients specified. Too bad there's not a simpler way to do that without duplicating code and arguments... In any case, the variable continues to be present in $Helo. Not in filter_sender if we use your patch, unless we parse the commands file manually. If you re-work your patch to leave filter_sender as it was, I will include it in the official release. Right, saw that. For some reason, all my postings are being delayed by 15 minutes or more... -Philip ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Jan Pieter Cornet wrote:
Also, your code assumes you cannot call smfi_setreply in the helo()
callback, but that assumption is wrong. At least, it is according to
the milter API documentation. It's probably very useful to set a reply
after HELO!
Ok, here are part of the revised diffs to mimedefang.c:
*** 556,561
--- 559,595
data-heloArg = NULL;
}
data-heloArg = strdup_with_log(helohost);
+
+ if (doHeloCheck) {
+ char buf2[SMALLBUF];
+ int n = MXHeloOK(MultiplexorSocketName, buf2, data-hostip,
+data-hostname, data-heloArg);
+ if (n == 0) {
+ set_dsn(ctx, buf2, 5);
+ /* We reject connections from this relay */
+ cleanup(ctx);
+ DEBUG_EXIT(helo, __LINE__, SMFIS_REJECT);
+ return SMFIS_REJECT;
+ }
+ if (n 0) {
+ set_dsn(ctx, buf2, 4);
+ cleanup(ctx);
+ DEBUG_EXIT(helo, __LINE__, SMFIS_TEMPFAIL);
+ return SMFIS_TEMPFAIL;
+ }
+ if (n == 2) {
+ set_dsn(ctx, buf2, 2);
+ cleanup(ctx);
+ return SMFIS_ACCEPT;
+ }
+ if (n == 3) {
+ set_dsn(ctx, buf2, 2);
+ cleanup(ctx);
+ return SMFIS_DISCARD;
+ }
+ }
+
+ DEBUG_EXIT(helo, __LINE__, SMFIS_CONTINUE);
return SMFIS_CONTINUE;
}
I'm wondering, however, if this is the correct handling... What about n
== 1?
Suggestion for the future... perhaps have an enum for these values
that's a little more intuitive.
-Philip
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Anyone noticing...
Matthew Schumacher wrote: If we had gone with iptables we wouldn't be able to leave our abuse, postmaster, and support addresses open, and users would be rejected without an error message explaining exactly what happened. Since rejected email only costs us one ldap and one sql lookup we will live with that since those things are really cheap compared to mimedefang and SA. iptables blocks in this context (or whatever kernel-level firewall system is available) are for the peristent host that simply WILL NOT STOP whatever rude activity it's doing. I've only ever had to use this once, against a freenet server that was opening SMTP connections ~5 times a second, starting the SMTP conversation (up to the sender IIRC)... and then stalling. Repeated, increasingly unhappy emails to the system's postmaster were accepted with no apparent effect. My final mail noted that I was dropping their server in my firewall due to persistent abuse (and included a short log extract - if I'd really been feeling annoyed that day I might have mailed the whole monster log), and that if and when they fixed their problem and contacted me (through an address handled by a different server) I would remove the entry. I removed it during a cleanup at one point about six months later and it hasn't happened again. -kgd ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
David F. Skoll wrote:
Not in filter_sender if we use your patch, unless we parse the
commands file manually.
If you re-work your patch to leave filter_sender as it was, I will
include it in the official release.
Here's the patch again. I was hoping to get some answers about the
set_dsn()
stuff before posting...
-Philip
--- examples/init-script.in.bak 2005-10-14 10:16:27.0 -0600
+++ examples/init-script.in 2006-01-17 00:58:34.0 -0700
@@ -39,16 +39,19 @@ [EMAIL PROTECTED]@
# If you want to keep spool directories around if the filter fails,
# set the next one to yes
# KEEP_FAILED_DIRECTORIES=no
# yes turns on the multiplexor relay checking function
# MX_RELAY_CHECK=no
+# yes turns on the multiplexor helo checking function
+# MX_HELO_CHECK=no
+
# yes turns on the multiplexor sender checking function
# MX_SENDER_CHECK=no
# yes turns on the multiplexor recipient checking function
# MX_RECIPIENT_CHECK=no
# Set to yes if you want the multiplexor to log events to syslog
MX_LOG=yes
@@ -212,16 +215,17 @@ start_it() {
printf %-60s Starting $prog:
rm -f $SOCKET /dev/null 21
$PROGDIR/$prog -P $PID \
-m $MX_SOCKET \
`[ -n $SPOOLDIR] echo -z $SPOOLDIR` \
`[ -n $MX_USER ] echo -U $MX_USER` \
`[ -n $SYSLOG_FACILITY ] echo -S $SYSLOG_FACILITY` \
`[ $MX_RELAY_CHECK = yes ] echo -r` \
+ `[ $MX_HELO_CHECK = yes ] echo -H` \
`[ $MX_SENDER_CHECK = yes ] echo -s` \
`[ $MX_RECIPIENT_CHECK = yes ] echo -t` \
`[ $KEEP_FAILED_DIRECTORIES = yes ] echo -k` \
`[ $MD_EXTRA != ] echo $MD_EXTRA` \
`[ $ALLOW_NEW_CONNECTIONS_TO_QUEUE = yes ] echo -q` \
-p $SOCKET
RETVAL=$?
if [ $RETVAL = 0 ] ; then
--- mimedefang.h.bak 2005-02-08 09:04:39.0 -0700
+++ mimedefang.h 2006-01-17 12:56:27.0 -0700
@@ -22,16 +22,18 @@ extern void write_percent_encoded(unsign
extern int percent_encode(unsigned char *in, unsigned char *out, int outlen);
extern void percent_decode(unsigned char *buf);
extern int MXCheckFreeSlaves(char const *sockname);
extern int MXScanDir(char const *sockname, char const *dir);
extern int MXCommand(char const *sockname, char const *cmd, char *buf, int len);
extern int MXRelayOK(char const *sockname, char *msg,
char const *ip, char const *name);
+extern int MXHeloOK(char const *sockname, char *msg,
+ char const *helo, char const *ip, char const *name);
extern int MXSenderOK(char const *sockname, char *msg,
char const **sender_argv, char const *ip, char const *name,
char const *helo, char const *dir, char const *qid);
extern int MXRecipientOK(char const *sockname, char *msg,
char const **recip_argv,
char const *sender, char const *ip, char const *name,
char const *firstRecip, char const *helo,
char const *dir, char const *qid,
--- mimedefang.pl.in.bak 2005-10-28 08:05:27.0 -0600
+++ mimedefang.pl.in 2006-01-17 13:00:34.0 -0700
@@ -5168,16 +5168,24 @@ sub do_main_loop () {
if ($_ =~ /^relayok (\S*)\s+(\S*)/) {
$ip = percent_decode($1);
$name = percent_decode($2);
relay_ok($ip, $name);
chdir($Features{'Path:SPOOLDIR'});
next;
}
+ if ($_ =~ /^helook (\S*)\s+(\S*)\s+(\S*)/) {
+ $ip = percent_decode($1);
+ $name = percent_decode($2);
+ $helo = percent_decode($3);
+ helo_ok($ip, $name, $helo);
+ chdir($Features{'Path:SPOOLDIR'});
+ next;
+ }
if ($_ =~ /^senderok (\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)\s+(\S*)/) {
$sender = percent_decode($1);
$ip = percent_decode($2);
$name = percent_decode($3);
$helo = percent_decode($4);
$CWD = percent_decode($5);
$QueueID = percent_decode($6);
$MsgID = $QueueID;
@@ -6494,16 +6502,44 @@ sub relay_ok ($$) {
# Set up globals
$RelayAddr = $hostip;
$RelayHostname = $hostname;
my($ok, $msg, $code, $dsn, $delay) = filter_relay($hostip, $hostname);
send_filter_answer($ok, $msg, filter_relay, host $hostip ($hostname), $code, $dsn, $delay);
}
#***
+# %PROCEDURE: helo_ok
+# %ARGUMENTS:
+# ip -- IP address of relay host
+# name -- name of relay host
+# helo -- arg to SMTP HELO command
+# %RETURNS:
+# Nothing, but prints ok 1 if we accept connections from this host.
+# ok 0 if not.
+#***
+sub helo_ok ($$$) {
+my($ip, $name, $helo) = @_;
+if (!defined(filter_helo)) {
+ send_filter_answer('CONTINUE', ok,
+ filter_helo, helo $helo);
+ return;
+}
+
+# Set up globals
+$RelayAddr = $ip;
+$RelayHostname = $name;
+$Helo = $helo;
+
+my($ok, $msg, $code, $dsn, $delay) =
+ filter_helo($ip, $name, $helo);
+send_filter_answer($ok, $msg, filter_helo, helo $helo,
+ $code, $dsn, $delay);
+}
+#***
# %PROCEDURE: sender_ok
# %ARGUMENTS:
Re: [Mimedefang] Adding filter_helo support
Hi, Philip. Here's the patch again. I was hoping to get some answers about the set_dsn() stuff before posting... Thanks! I believe set_dsn() will work in the HELO callback. I will integrate your patch. (Btw, I've noticed that almost no patch submitters remember to update the man pages! :-)) Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Adding filter_helo support
I've kind of lost the thread here what is the recommended use for filter_helo? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Gary Funck wrote: I've kind of lost the thread here what is the recommended use for filter_helo? Philip wanted an opportunity from MIMEDefang to change how Sendmail reacts to the HELO/EHLO command. Right now, you can't; you have to wait for MAIL FROM: to do anything based on the HELO argument. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Adding filter_helo support
Philip wanted an opportunity from MIMEDefang to change how Sendmail reacts to the HELO/EHLO command. Right now, you can't; you have to wait for MAIL FROM: to do anything based on the HELO argument. OK, and what about the question raised as to how incoming mailers might react if, for example, tempfailed at HELO time, and related questions? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
David F. Skoll wrote: (Btw, I've noticed that almost no patch submitters remember to update the man pages! :-)) Not true! ;-) I updated the man page, but that also included edits for changing filter_sender(), which I then had to back out... -Philip ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Adding filter_helo support
Seems to be working:
Jan 17 08:10:01 mail sendmail[24471]: NOQUEUE: connect from
san-cust-208.57.14.2.mpowercom.net [208.57.14.2]
Jan 17 08:10:01 mail sendmail[24471]: AUTH: available mech=DIGEST-MD5
ANONYMOUS
CRAM-MD5, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
Jan 17 08:10:01 mail sendmail[24471]: k0HFA1UP024471: Milter
(mimdefang): init success to negotiate
Jan 17 08:10:01 mail sendmail[24471]: k0HFA1UP024471: Milter: connect to
filtersJan 17 08:10:01 mail mimedefang.pl[23065]: relay: 208.57.14.2,
san-cust-208.57.14.2.mpowercom.net
Jan 17 08:10:01 mail mimedefang.pl[23065]: relay: matches 0.0.0.0/0
(CONTINUE: OK)
Jan 17 08:10:01 mail mimedefang.pl[23065]: helo:
san-cust-208.57.14.2.mpowercom.net (208.57.14.2) said helo 10.0.0.36
Jan 17 08:10:01 mail mimedefang.pl[23065]: no brackets: 10.0.0.36
Jan 17 08:10:01 mail mimedefang.pl[23065]: filter_helo rejected helo
10.0.0.36
Jan 17 08:10:01 mail sendmail[24471]: k0HFA1UP024471: milter=mimdefang,
action=helo, reject
Jan 17 08:10:01 mail sendmail[24471]: k0HFA1UP024471: Milter:
helo=10.0.0.36, reject=Command rejected
Here's a fragment of my script:
sub filter_helo($$$) {
my ($hostip, $hostname, $helo) = @_;
md_syslog('info', helo: $hostname ($hostip) said \helo $helo\);
# dotted quads need to be bracketed
if ($helo =~ /^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/) {
md_syslog('info', no brackets: $helo);
return ('REJECT', Incorrect format for address-literal);
}
# ok, got the format right... now is the address correct?
# this might be wrong if our clients are behind a NATting gateway;
# if that's the case, we need to preface this with accepting everyone
# whose $hostip matches a certain address or address range
if ($helo =~ /^\[(\d{1,3})\.(\d{1,3}).(\d{1,3})\.(\d{1,3})\]$/) {
if ($helo ne [$hostip]) {
md_syslog('info', wrong ip: $hostip claims to be $helo);
return ('REJECT',
Header forgery attempt, [$hostip] claims to be $helo);
}
}
# put this in explicitly, in case the test below is disabled.
if ($helo eq 'localhost') {
md_syslog('info', localhost: $hostip ($hostname));
return ('REJECT', Nothing local about you);
}
# doesn't contain any dots
if (index($helo, '.') == -1) {
md_syslog('info', not fqdn: $helo);
return ('REJECT', Expected fully-qualified domain name);
}
return ('CONTINUE', OK);
}
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Slaves dying unexpectedly with signal 14
Hi All, I posted an email some time back asking about MD slaves that were unexpectedly terminating with a signal 14. David Skoll mentioned at the time that it was possibly a perl module generating this signal 14 which was somehow not being handled and was causing the slaves to die. At the time, I upgraded a few of the perl modules, and the problem seemed to go away. Unfortunately, it is back. Once the errors start occuring, a restart seems to stop it happening for a time, but eventually, it returns. This error is occuring on two seperate mail exchangers (Which are running the same software versions). I am running mimedefang 2.53 under CentOS linux 3.6 Can anyone give me any pointers at all as to how I can go about further tracking down what is generating these signal 14's?? Can I arm some sort of signal handler in my filter and generate some sort of trace back? Any sort of help would be appreciated. The log messages I am getting are as follows: snip Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Slave 4 died prematurely -- check your filter rules Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Reap: Idle slave 4 (pid 10634) exited due to signal 14 (SLAVE DIED UNEXPECTEDLY) Jan 18 19:00:57 hosta mimedefang-multiplexor[6464]: Slave 4 resource usage: req=44, scans=8, user=14.830, sys=1.360, nswap=0, majflt=10062, minflt=111990, maxrss=0, bi=0, bo=0 Jan 18 19:00:57 hosta mimedefang[6477]: Error from multiplexor: ERR No response from slave /snip Thanks Roland ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
