Am Freitag, den 28.07.2006, 13:24 -0400 schrieb Noel J. Bergman: > 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
After the "bug" i checked how postfix handle it. Postfix reject an invalid EHLO/HELO on the RCPT. So we (I) should change it. I will change it in the trunk only.. then we can vote for fix it in 2.3 or in 2.4. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
