[Mimedefang] Not piggybacking HELO checks

[Philip Prindeville]

David F. Skoll wrote:

>Philip Prindeville wrote:
>
>  
>
>>BTW:  Are there patches to support calling filter_helo directly, rather
>>than bundling it as part of filter_sender?
>>    
>>
>
>Not that I'm aware of.
>
>  
>
>>Here's why:  certain sites that don't get a lot of external mail but do
>>need to be "open" to the outside all the same (and no email addresses on
>>these machines are published in any way to the outside world) have
>>open security, i.e. they will answer a "EXPN" or "VRFY".
>>    
>>
>
>  
>
>>But they shouldn't do this if a connection comes in from a site we don't
>>trust, and indeed if we see a bogus HELO, I'd like to give a 5xx
>>response right then and there.
>>    
>>
>
>This seems like pretty weak security to me.  Is there a valid reason for
>having sites answer to an EXPN or VRFY?
>  
>

Agreed that it's weak security: some legacy management software requires it.

But... that doesn't change the fact that having individual knobs and 
controls
provides finer tuning...  And it might be nice to block the connection 
before
we've exposed too much information.


>>So... what's involved in getting mimedefang to look at and respond
>>to the HELO command directly?
>>    
>>
>
>You'd need to rework the C code and come up with a mimedefang <->
>multiplexor <-> slave protocol for doing it.  It's not too hard, but I
>won't do it unless someone submits a clean and ready-to-go patch.  I
>don't think the effort is really worth it.
>
>Regards,
>
>David.
>  
>

Well, from a purely architectural point of view... a symmetrical design 
would
provide a control hook at each transition point in the state machine...

I could work on it myself, but I lack familiarity with the code.

-Philip