email address anti-spam encoding in portfiles

James Berry jberry at macports.org
Thu May 17 21:11:03 PDT 2007


On May 17, 2007, at 10:41 AM, Ryan Schmidt wrote:

>
> On May 17, 2007, at 06:00, Ian Eiloart wrote:
>
>> On 16 May 2007 17:12:10 -0700 James Berry wrote:
>>
>>> Following discussion with several of you, and more thought, my  
>>> thinking
>>> is now:
>>>
>>> 	(1) Obfuscate plain text email addresses by using the form:
>>>
>>> 		- tld/domain/username
>>> 			user at bar.com ==> com/bar/user
>>>
>>> 		- if there are multiple components in the hostname, only the  
>>> dot before
>>> the tld is turned into a slash:
>>> 			user at foo.bar.com ==> com/foo.bar/user
>>
>> This won't always work (at least, not with simple  
>> implementations), since a slash is legal in an email local part  
>> (though often banned by local policy). However, if you used  
>> "subdomain.tld/localpart" you'd be OK, since the first slash would  
>> always be the separator.
>
> I'm also concerned that this looks silly/weird for people whose  
> email addresses are at CCTLDs where the last two components of the  
> email address usually "go together". For example, if your email  
> address is at "mail.example.edu", then it's somewhat ok to encode  
> this as "edu/mail.example", since "mail.example" is the part that  
> the school has control over while "edu" is the part they don't  
> control. However, in the case of Ian, encoding "sussex.ac.uk" as  
> "uk/sussex.ac" makes less sense/looks more strange, since "ac.uk"  
> goes together (is the UK equivalent of "edu").

Good point.

> So I would be in favor of changing user.name at mail.example.com into  
> mail.example.com/user.name. Or com.example.mail%user.name. Or  
> something. But in any case making it clear (to both people and  
> machines) which part is the local part and which part is the domain  
> part (which as Ian said is not possible when you use multiple  
> encoding characters to split the domain part into multiple parts).

As Ian pointed out, / isn't really good as it's a valid atext  
character from rfc 2822. So what if we head back to Salvatore's  
suggestion of:

	suxxex.ac.uk:iane

That's more readable, and unlikely to be recognized by the spambots.

James



More information about the macports-dev mailing list