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
_______________________________________________
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 [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
