Stefano Bagnara schrieb: > I did a small review of the current SMTPSession.getUser() calls inside > the handlerapi-experiment sandbox. > > SMTPSession.getUser() is called by all this RcptHooks: > o.a.j.s.c.filter.fastfail.ResolvableEhloHeloHandler.doRcpt() > - if ((session.getUser() == null || checkAuthUsers)) do the check > o.a.j.s.c.AuthRequiredToRelayRcptHook.doRcpt() > - if (!session.isRelayingAllowed() && session.getUser() == null) do > the check > o.a.j.s.c.filter.fastfail.DNSRBLHandler.doRcpt() > - if (session.getUser() == null) do the check > o.a.j.s.c.filter.fastfail.GreylistHandler.doRcpt() > - if (!session.isRelayingAllowed() && session.getUser() == null) do > the check > o.a.j.s.c.filter.fastfail.SPFHandler.doRcpt() > - if (session.getUser() == null) do the check > o.a.j.s.c.filter.fastfail.ValidRcptHandler.doRcpt() > - if (!session.isRelayingAllowed() && session.getUser() == null) do > the check > > These 3 instead really read the username (one for "logging", one other > for checking, one to see if the user already authenticated) > o.a.j.s.c.AuthCmdHandler.doAUTH() > - if (session.getUser() != null) return error:bad_sequence > o.a.j.s.c.SenderAuthIdentifyVerificationRcptHook.doRcpt() > o.a.j.s.c.AddDefaultAttributesMessageHook.onMessage() > > About the 6 RcptHooks that currently check for "getUser() == null" I > think we have few inconsistencies: > > 1st) only ResolvableEhloHeloHandler have a "checkAuthUsers" option: do > we need that check only there? do we need it in every of this RcptHooks?
I whould remove this. I think we can use a generic config variable which check for authenticated user and allowed relays... > > 2nd) 3 of that RcptHooks call !session.isRelayingAllowed() in and with > the getUser==null call: is it the wanted behaviour: do we want to > extend this to every handler? This makes sense because if this not match the user is allowed to really > > My current suggestions: > > A. Should we simply make the default AuthHandler to add a > setRelayingAllowed to true after succesfull authentication? Is there > any drawback doing this? Imho it would be simpler and cleaner. +1 > > B. Maybe we should add an RcptHook that simply return HookRetCode.OK > if the user is authenticated, so that adding that check before all of > this handlers will already do the trick, and moving it up-down in the > chain will provide the "checkAuthUsers" behaviour to every handler. Well i see some problems here. This will make it impossible to call a hook for a auth user even if the user/developer want this. Maybe he want to create a hook which only is used for authenticated RCPT. So this is IMHO not the right solution. But i understand that it is annyoing to have to configure it on every hook. Maybe thats the price we have to pay :-( > > Any thought? > > Stefano > bye Norman Ps: Thx for writting this email . --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
