Re: [exim] Really Cool Trick

Chad Leigh -- Shire.Net LLC wrote:

>
> On Oct 19, 2006, at 3:10 PM, W B Hacker wrote:
>
>>
>> If one simply insists on a domain-wide differentiator, such as a
>> prefixed/suffixed address format:
>>
>> <folder/listname>.<real_user>@<domain.tld>
>>
>> or
>>
>> <real_user>.<folder/listname>@<domain.tld>
>>
>> or <whatever_else_you_wish_to_parse_embedded_local_part>@<domain>.<tld>
>>
>> Then *ALL* IMAP users may have this feature. No symlinks required.
>>
>> CAVEAT: Best to NOT allow the router/transport code for this special
>> structure
>> to create folders that do not pre-exist.
>>
>> ELSE you have a catch-all-builder that dictionery attacks may exploit.
>>
>> - Though one can see uses for that as a 'feature' as well...
>
>
> We have a setup where accountname*folder@domain will be delivered
> straight to the folder and will auto create the folder. This has not
> been a problem since they have to know the original accountname and a
> dictionary attack against the accountname alone is just as easy as one
> with accountname*folder . This allows the users to, at the spur of the
> moment, create new folders when entering in email addresses on web
> forms, etc, without having to remember to create the folder in their
> mua. The downside is that they cannot turn off such addresses since
> they will be autocreated. (I have had to go in change the protections
> on the folder so that the MTA cannot write into it).


> I am thinking
> about how to allow the autocreate of folders but have a user
> administrable way (no local logins for the users) to be able to turn
> off a folder and make it inactive.
>

/CAVEAT: Not for everyone.

That is handled here in the SQL DB that controls the specification of how and
where the storage is to be done, and IF it is to be done.

An SQL DB can be managed by a user interface that does not require granting
direct end-user access to the MTA, does not rely on the Unix perms system, does
not (necessarily) need to even reside on the same box, and has its own very rich
set of rights management.

/CAVEAT

> where * = our special character, not an asterisk
>
>
> Chad
>
>>
>> One might also wish to provide each user with a dynamically- generated
>> alias as
>> damage control against address harvesting.
>
>
>
>
>
> ---
> Chad Leigh -- Shire.Net LLC
> Your Web App and Email hosting provider
> chad at shire.net
>
>
>