To recap, Matt Comer wrote: (Sat, 15 Mar 2008 09:04:20 -0400 (EDT)) > <quote who="Alessandro Vesely"> >> Authmysql needs to be revamped. I'd propose to accept any local-part >> that can be the target of an RCPT TO command [context log, with localpart=info's] >>> authd: SQL query: SELECT email, "", clear, uid, gid, home, maildir, >>> quota, "", "" FROM users WHERE email = "info [EMAIL PROTECTED]" >>> >>> imapd: LOGIN FAILED, user=info'[EMAIL PROTECTED], ip=[::ffff:127.0.0.1] >> >> There is an inconsistency between get_localpart() [AND] >> rfc2821 >> Local-part = Dot-string / Quoted-string ; MAY be case-sensitive >> Quoted-string = DQUOTE *qcontent DQUOTE > > I agree, but with one possible caveat: most RDBMSs allow you to configure > the quoting behavior away from the default if you want.
But then Gordon Messmer wrote: (Sat, 22 Mar 2008 23:33:20 -0700) > Alessandro Vesely wrote: >>> I'd use mysql_real_escape_string(), if available. See >>> http://bugs.mysql.com/bug.php?id=10214 > > No, you should never use any escape function on user input if it can be > helped. Prepared statements are the most convenient However, we've learned that using prepared statements may break user's configuration. Thus, its use should better be introduced with a separate module, authmysql2, say. There is another question on the same subject. Consider MAIL FROM:<"\"back\\slash\""@example.org> We have a "semantic" local part, "back\slash" with the quotes and the backslash, that is different from the literal one. Courier currently delivers the literal local part. However, it may be smarter for the auth module to also allow searching for the semantic value. Should it? And, if it should, can it use a common quote-stripping function? A similar concern arises for SPF macros, another place where a common quote-stripping function may be used (hm... it's in a different package.) Let me quote from http://www.listbox.com/member/archive/1007/2008/04/sort/thread/page/1/entry/14:22/20080414164951:516D36A4-0A64-11DD-865F-CCB452096D31/ Frank Ellermann wrote: (Mon, 14 Apr 2008 22:52:09 +0200) > I don't see why MTAs should suddenly start to be smart. They > get an address with a <quoted-string> as local part, and they > pass this on to SPF with a clear directive "now do your magic, > I want PASS or FAIL, a.s.a.p.". > > MTAs have no reason to figure an odd "semantical content" out, > that's hardcore standardista stuff, not practical programming. > > SPF has to do this - something above checkhost() is fine, but > not so far above checkhost() that it is outside of SPF. There > is no "duty" for MTAs or other SPF users to parse a MAIL FROM > address into its "semantical content". > > I'd even fear that nothing removes the reverse route in cases > where it's present. RFC 4408 clearly says "strip it". It's > the job of SPF to strip a reverse route, therefore it's also > the job of SPF to deal with <quoted-string> + <quoted-pair>. > > And it's not something that still works if done twice, if an > MTA really already did it SPF must not try it again, example: > > MAIL FROM:<@example.com:"\"back\\slash\""@example.org> > > The semantical content of the local part is "back\slash" with > the quotes and the backslash. > > Frank ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
