[Mimedefang] Testing for port #/TLS in filter_relay

Philip Prindeville philipp_subx at redfish-solutions.com
Thu Feb 28 17:31:36 EST 2008


Jan-Pieter Cornet wrote:

> 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)
>   

Ok, so...  let's step back a moment.  What's the barrier to passing
Sendmail Macros to mimedefang at the relayok time?

Do they need to become additional arguments, or what?  Does the Milter
API need to change?

I'm befuddled as to what the point of "O Milter.macros.connect" is, if
it isn't easily passed through the Milter API...


> 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}'')
>   

Right, but what happens then?

(And what's the downside of these becoming part of the permanent list in
cf/m4/cfhead.m4?)


>> 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.
>   

Gah!  The manual was right and the source code was wrong?  That's got to
be a first!  :-)


> 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.
>   

And I fell for it, too.


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

Ok, so... back to the original question:  How do the O Milter.macros.*
stuff get passed through then?

(No, I've not read the actual Milter API...  not had the time.  Alas.)

>> 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?


Because I want to do this in filter_relay(), so it seems to be a moot
point which %SendmailMacros I use, since none of them are available at
that point.

Sigh.


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


That doesn't work for me.  I was hoping to be able to install a
temporary packet filter (via iptables) as part of a call-out script from
mimedefang-filter to block further connections (since they tend to come
in flurries that spike my server CPU cycles and cause other connections
to get dropped).

-Philip







More information about the MIMEDefang mailing list