On 12/Oct/10 03:32, Sam Varshavchik wrote: > Alessandro Vesely writes: > >> *opaque authentication address in Received* >> This is the "AUTH: [email protected]" snippet of the Received line.
Oops, I meant "AUTH: CRAM-MD5 [email protected]". >> This patch provides an option to avoid disclosing that address, by >> reusing the /fullname/ field, that is not otherwise used in STMP-AUTH. > > This part of the code is a bit hard to follow. Not that the existing > code is a model of clarity, but I'd like to think that after ten years > my standards have improved… Admittedly, re-using an existing field for unrelated purposes is a bit hackish. But adding record numbers in authlib is overkill... > Presumably the message will carry the sender's address anyway, so I > don't see the value added that this brings. Various clients support using multiple identities in "From", while maintaining unique-per-server id-password pairs. A use case is for people using role addresses. One may write as, say, [email protected], but is actually authenticated as [email protected], because that's how she has configured her client. > Furthermore, I just know that, at some point later down the road > the issue of using names that have non-Latin 8-bit characters will > come up. I don't think now is the right time to tangle this. Yeah, I expect that header fields can just have plain utf-8 values. This may happen soon: A second round of i18n RFCs is scheduled for Jul-Sep 2010, according to [EAI]. While the first round consisted of experimental RFCs, these ones will be Proposed Standard. BTW, I've been puzzled by the existing test (in auth_callback_func) for (p=authuserbuf; *p; p++) if ((int)(unsigned char)*p < ' ' || *p >= 127) *p=' '; Apparently, it allows utf-8, and, since the first token has already been checked by authlib, any overriding space won't be mistaken for a token separator. I guess this is part of what you don't consider a model of clarity. I've never tried an internationalized address, but I've read Courier supports them. So, can that string be utf-8? At any rate, the patch kept the same test for the 2nd token. As I don't think non-ascii stuff in "Received" makes much sense anyway, and need to guard against extraneous punctuation, the patch restricted the 3rd token (fullname) to chars such that isalnum(ch) || strchr("@-.", ch) which implies 7bit, under the "C" locale. > The other stuff, the change in the received: header format and the > space stripping, that looks fine. I rolled it into > courier-0.65.1.20101011.tar.bz2 Thanks a lot! However, there may be an error there. I get the following: The "/courier-devel/20101011/courier-0.65.1.20101011.tar.bz2" file could not be found or is not available. Please select another file. -- [EAI] http://datatracker.ietf.org/wg/eai/charter/ ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
