Am Samstag, den 29.07.2006, 19:18 +0200 schrieb Vincenzo Gianferrari Pini: > > Norman Maurer wrote: > > >>Noel J. Bergman wrote: > >> > >> > >>>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] > >>> > >>> > >>Yes, of course. There are plenty of changes and improvements that can be > >>done here, but we are in RC and I'm replying to a message related to an RC. > >> > >>We have the filter in that place, we will not move it around at rc > >>level, as it is not a bug. (IMO) > >> > >> > IMO it *is* a bug :-) , because IMHO it is unusable the way it is now. > But it is a bug in an optional (not terribly important) *new* feature of > 2.3.0, absent in 2.2.0, so keeping it unresolved will not hurt any > existing James system. It was a different story for the JAMES-580 bug in > the old <checkValidSenderDomain> feature. > > And after seeing Norman's fix to trunk, I think that it would be too > dangerous to backport it to 2.3.0rcn, and would need too much real > testing. So better to delay it to 2.4, to help releasing 2.3.0 final sooner. > > But being an unresolved bug (again :-) ), the <checkResolvableHelo> and > <checkResolvableEhlo> entries should not appear (even commented out) in > the 2.3.0 stock james-smtphandlerchain.xml at all.
I disagree. I added some WARNING to the config to tell the exact behavoir. That should be enough. If someone use it only as relay ( like i do) the current behavoir is ok. > > >> > >>Instead, as time passes, my idea for delaying it to 2.4 is stronger. > >> > >>Again I could change ideas about things to put in 2.3 if we'll find > >>blocker issues and the 2.3.0 final will be delayed anyway. > >> > >>If we release 2.3.0 final soon we can start working on 2.4 and add this > >>and much more new features! > >> > >>Stefano > >> > >> > > > >After i did now the changes i whould like to "delay" the improvment to > >2.4. Let us release the handler like it is at the moment and add an > >comment how it works to the configuration. > > > >So: > > > >2.4 -> +1 > > > >2.3 -> -0 > > > >bye > >Norman > > > > > If asked I would right now vote: > > 2.4 -> +1 > > 2.3 -> -1 > > Vincenzo Ok so we agree. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
