[Mimedefang] Testing for port #/TLS in filter_relay

[Jan-Pieter Cornet]

On Wed, Feb 27, 2008 at 06:26:14PM -0800, Philip Prindeville wrote:
> >Well, I could just test for auth_type or tls_version, but my 
> >understanding is that this isn't available as early on as 
> >filter_relay() and filter_helo()...  that the commands file doesn't 
> >get read until filter_sender(), right?

The COMMANDS file doesn't exist until filter_sender().

> >      read_commands_file()
> >             This function should only be called from filter_sender 
> >and  fil-
> >             ter_recipient. This will read the COMMANDS file (as 
> >described in
> >             mimedefang-protocol(7)), and will fill or update  the  
> >following
> >             global   variables:   $Sender,  @Recipients,  
> >%RecipientMailers,
> >             $RelayAddr, $RealRelayAddr, $RelayHostname,  
> >$RealRelayHostname,
> >             $QueueID, $Helo, %SendmailMacros.
> >
> >
> >Or am I missing something?
> >
> >Will the milter API support passing the port # at filter_relay() time?

Yes, it will. It's mimedefang that doesn't support it. But hey, this is
open source. I'm sure that if you come up with a decent path to support
it, it might get incorporated :) (still, passing macro's in mimedefang is
somewhat shaky, for example, you cannot pass the explicit macro's that
are set in the RCPT TO phase)

> define(`confMILTER_MACROS_CONNECT', ``j, _, {daemon_name}, 
> {daemon_port}, {if_name}, {if_addr}'')dnl
> 
> (Which reminds me... anyone on this list cozy with the Sendmail folks?
> This might be a useful change to make to the standard cf/m4/cfhead.m4
> file...)

Since you can easily add to this list yourself. I use this construct
to add {msg_size} to the list of macro's passed during envfrom:

    dnl # pass extra macros to milter/mimedefang... without repeating
    dnl # what cfhead defined `confMILTER_MACROS_ENVFROM' to.
    define(`ORIG_confMILTER_MACROS_ENVFROM', confMILTER_MACROS_ENVFROM)
    define(`confMILTER_MACROS_ENVFROM',
		`ORIG_confMILTER_MACROS_ENVFROM, `{msg_size}'')

> and remade the .cf file, then restarted Sendmail.  Then added
> read_commands_file() into filter_relay(), and got:
> 
> Feb 27 18:35:21 mail mimedefang.pl[16628]: Cannot open COMMANDS file 
> from mimedefang: No such file or directory
> Feb 27 18:35:21 mail mimedefang[2683]: Error from multiplexor: error: 
> Cannot open COMMANDS file from mimedefang: No such file or directory
> Feb 27 18:35:21 mail sendmail[16635]: m1S1ZLZg016635: Milter: connect: 
> host=notorious.mozilla.org, addr=63.245.208.166, temp failing commands
> 
> What am I missing?  Looking at the comment in mimedefang.pl, it says:

As it says in the manual, you cannot call read_commands_file in
filter_relay.
 
> #***********************************************************************
> # %PROCEDURE: read_commands_file
> # %ARGUMENTS:
> #  needf - if true, will return an error when no closing "F" was found.
> #          (optional, default is false). needf should not be set when
> #          called from within filter_relay, filter_sender, filter_recipient.

Oops. this comment is misleading - it says "needf should not be set when
called from within filter_relay...". That falsely gives the impression you
can actually call this function from within filter_relay. You can't.

[...]
> Which seems to negate the previous comment from the man page (usually
> I'll trust source code over what the man pages say, since they aren't
> always up to date).
> 
> Doh!  envfrom() in mimedefang.c needs to be modified...  Or else I need
> to pass in extra macro names via -a (as a temporary measure).  Ok, even
> after trying that (-a daemon_port), I'm still not seeing it...  Grrr.
> In fact, %SendmailMacros doesn't seem to get populated until filter_begin().

It will if you call read_commands_file(), but that can only be done in
filter_sender or filter_recipient

> David:  how about it?  Can we add 'daemon_port' to the list of default
> macros in envfrom()?

Why don't you use the various {auth_*} macro's to verify that the
connection is authenticated, before dropping it?

That does mean you will have to delay dropping the connection until
at least after filter_sender.

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disclamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please !!
!! archive this message indefinitely to allow verification of the logs.  !!