Alessandro Vesely writes:
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.
Ok, so they know the login address. Ok, now what? I suppose that the stock argument would be this is partial disclosure, exposing a potential dictionary attack.
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.
Oh well.
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.
Yes, trusting will be sufficient. This code can be completely dropped, as well as all the various bits that complain about 8-bit headers.
I'll probably do it soon, in advance. Looks like things are heading into this direction, so there.
pgpgUgCVhfcua.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
