[Mimedefang] MIMEDefang 2.55 is released

[Philip Prindeville]

David F. Skoll wrote:

>Doh!  I forgot.  I added it to the generic startup script, but
>not the Red Hat ones.  Thanks to all the beta testers who caught that! :->
>  
>

Actually, that should have been in the original set of diffs that I 
submitted.

They must have gotten dropped somewhere along the way. :-(

>To be honest, I don't think filter_helo is useful.  It has the same
>effect as filtering on HELO during MAIL (because of the way Sendmail
>works), so I really think it's a waste of time.
>  
>

I've been talking to Claus about this.

I've attached a copy of part of my email to him.

-Philip


>However, for consistency, I suppose we should add MX_HELO_CHECK support
>to the Red Hat init files.
>
>Regards,
>
>David.
>  
>
--------
I went ahead and contributed Milter support for filter_helo to Mimedefang
(it should be in 2.55-FINAL).

During testing, however, we noticed that even if the rule that fired in 
the HELO
stage resulted in a REJECT, then the answer would still be a 250, and 
that the
failure would be deferred to the MAIL FROM:

% telnet mail.redfish-solutions.com 25
Trying 71.36.29.88...
Connected to mail.redfish-solutions.com.
Escape character is '^]'.
220 mail.redfish-solutions.com ESMTP Sendmail 8.13.1/8.13.1; Fri, 20 Jan 
2006 14:19:59 -0700
helo localhost
250 mail.redfish-solutions.com Hello willers.employees.org 
[192.83.249.36], pleased to meet you
mail from:<philipp at xyzzy.org>
554 5.7.1 Nothing local about you
quit
221 2.0.0 mail.redfish-solutions.com closing connection
Connection closed by foreign host.
%

(and on the server side:)

Jan 20 14:19:59 mail sendmail[8179]: NOQUEUE: connect from 
willers.employees.org [192.83.249.36]
Jan 20 14:19:59 mail sendmail[8179]: AUTH: available mech=DIGEST-MD5 
ANONYMOUS CRAM-MD5, allowed mech=EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 
LOGIN PLAIN
Jan 20 14:19:59 mail sendmail[8179]: k0KLJxHx008179: Milter (mimdefang): 
init success to negotiate
Jan 20 14:19:59 mail sendmail[8179]: k0KLJxHx008179: Milter: connect to 
filters
Jan 20 14:19:59 mail mimedefang.pl[7506]: relay: 192.83.249.36, 
willers.employees.org
Jan 20 14:19:59 mail mimedefang.pl[7506]: relay: matches 0.0.0.0/0 
(CONTINUE: OK)
Jan 20 14:20:03 mail mimedefang.pl[7506]: helo: willers.employees.org 
(192.83.249.36) said "helo localhost"
Jan 20 14:20:03 mail mimedefang.pl[7506]: localhost: 192.83.249.36 
(willers.employees.org)
Jan 20 14:20:03 mail mimedefang.pl[7506]: filter_helo rejected helo 
localhost
Jan 20 14:20:03 mail sendmail[8179]: k0KLJxHx008179: milter=mimdefang, 
action=helo, reject=554 5.7.1 Nothing local about you
Jan 20 14:20:03 mail sendmail[8179]: k0KLJxHx008179: Milter: 
helo=localhost, reject=554 5.7.1 Nothing local about you
Jan 20 14:20:45 mail master[4573]: process 8173 exited, status 0

I understand why this is done: strict compliance to the RFC.

However, should the code be modified to allow the user to elect to be 
strictly
complaint (make a mental note that this connection is suspect, and fail 
it out
when we hit the filter_sender() stage)... or else to refuse the connection
immediately?

Here's why.  Suppose that a virus or worm or other DOS attack was being
propagated via email which Sendmail or something downstream was
susceptible to...  Further suppose that this agent has some fingerprint that
makes it identifiable during the HELO stage, before the state machine
enters a state where Sendmail becomes exploitable.

In that case, I think I'd put self-preservation about strict RFC compliance
(since a crashed or subverted machine isn't compliant in any case).

How about adding a switch or knob that allows the HELO rejection in
the Milter to be effective immediately, or even making that the default
action?