On 13/Oct/10 00:08, Sam Varshavchik wrote: > Alessandro Vesely writes: >> 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. > > Yes, I understand that, but I don't see how the logging information in > Received: headers, which most people don't even see, makes a > difference here.
If /some/ people sees it, by Murphy's law they will be the ones the poor postmaster would never have wanted to learn about such link... Never mind. A real operational difference will arise for users having utf-8 login IDs. My understanding is that, since EAI gave up automatic address degradation, those users will need all-ascii addresses that can be used for manually degrading their non-ascii counterparts, in order to reach legacy systems. For such manual degradation to work, it will have to also affect the "Received" field. This is not yet actual; draft-ietf-eai-frmwrk-4952bis has seen its 10th revision, so it seems to be just a few months behind schedule. I think you will modify Courier in order to allow utf-8 addresses. Then, I'll modify this patch accordingly, if still needed :-) >> 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? > > No. That code above replaces all control characters and high bit > characters with a space character. It won't accept utf-8. Then it's a bug: *p cannot be > 127, because it's signed. > This is due to interaction with the code that rejects mail, by > default, that has 8 bit header content. I understand this point. But what effect will those overriding spaces have on the address? When utf-8 will be allowed, will this token have to be checked for consistent encoding? Since it comes from authlib, trusting it may be an acceptable design choice. -- ------------------------------------------------------------------------------ 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
