Re: [Mimedefang] Adding filter_helo support
I was just thinking... We don't export any of the Sendmail variables into
the filter_helo() code:
O Milter.macros.helo={tls_version}, {cipher}, {cipher_bits},
{cert_subject}, {cert_issuer}
What to do about that?
-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
On Tue, Jan 31, 2006 at 01:23:08AM -0700, Philip Prindeville wrote:
I was just thinking... We don't export any of the Sendmail variables into
the filter_helo() code:
O Milter.macros.helo={tls_version}, {cipher}, {cipher_bits}, {cert_subject},
{cert_issuer}
What to do about that?
Nothing. Those that want to inspect those macro's, will already use
the mimedefang -a option to add more macro's, and retrieve those at the
appropriate moment... which is likely the MAIL From phase, not the HELO
phase (it's not even guaranteed those are set when you get to the HELO
stage, most mailers say HELO first and then use STARTTLS).
--
#!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] Adding filter_helo support
On Tue, Jan 17, 2006 at 03:33:38PM -0800, Gary Funck wrote:
OK, and what about the question raised as to how incoming mailers
might react if, for example, tempfailed at HELO time, and related
questions?
I asked that merely out of curiousity, since it's not common to reject
after HELO, so it's probably not well tested. It's not a requirement for
integrating the patch (but if it causes surprising interaction with
other mail programs, that might be worth documenting).
It's good that mimedefang offers a more complete interface to the milter
API... only xxfi_abort and xxfi_close left to do (and I do see some good
use for those, so with any luck I'll add support for them later on).
--
#!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] 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] 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] 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] 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] 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] 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] Adding filter_helo support
Working on adding filter_helo support... 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... Inquiring minds want to know... Digging... -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
Quick question...
I was wondering about moving the:
write_mx_command(data-cmdFD, 'E', (unsigned char *) data-heloArg);
into the helo() function from envfrom() instead... but I'm not sure at
what point
the file is opened and can be written to... currently that happens in
envfrom()
too, but... it's not clear what stuff that can't happen in mfconnect
because it's
too early can happen in helo instead of envfrom().
Also, what about including write_macro_value() calls for:
{tls_version}, {cipher}, {cipher_bits}, {cert_subject}, {cert_issuer}
since this might be of interest in filter_helo() as well.
Thanks,
-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
