Stefano Bagnara wrote:
> the EHLO/EHLO is done before the AUTH can be issued so we only
> have a "checkAuthNetworks" option and not a "checkAuthClients"
> option like we did for other CmdHandlers.
Sometimes, you have to defer the problem that you caught, so if the command
handler finds the problem, it can set a session attribute itself (or another
aware handler) to deal with later.
For example, the block list code is intentionally handled in RCPT because I
wanted to defer the error until we knew to whom they were sending the
e-mail, thus allowing RFC compliance with postmaster@ and [EMAIL PROTECTED]
The concept, for which we now have support in the v2.4 changes, was that an
"EHLO" handler could actually be a suite of related handlers registered to
be an EHLO handler, an AUTH handler, and some other type of handler(s), so
that it could set a detected concern in EHLO, possibly clear it in AUTH, and
check it downstream.
I've not formed an opinion on whether or not to fix this for v2.3 or wait
for v2.4. I won't form an opinion until I see the proposed patch.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
