> They why have a catch-all at all? Isn't this the same as having

> multiple email addresses that deliver to the same account? i.e.

> aliases.

 

Not the same.

 

If I have a bunch of aliases, I must create those aliases in advance, else the 
mail gets bounced.

 

If I have a catchall that goes to quarantine, and a whitelist which skips 
quarantine, I can dish-out random addresses to people/robots willy nilly.  I 
prefer to never give out the same email address twice.  Then I can look through 
the quarantine to selectively whitelist anything that was truly intentional.  
If a spammer floods me with random character addresses ... the worst he can do 
is flood my quarantine.

 

In fact, since practical implementations of exchange don't support catchall, I 
am currently using a few hundred aliases.  It's the 2nd best available 
alternative to having a catchall.

 

Conceptually, the same thing could be accomplished with plus addressing.  Just 
take the part that would be before the @ in a catchall, and use that as the 
part after the + in the plus addressing.  Only problem is the widespread 
incompatibility of plus addressing in general.  Websites and people who refuse 
to take that address, mail systems that can’t support it, either sending or 
receiving, etc.

 

 

> > I've been exceptionally happy with this setup for years.  I only wish

> there

> > were better tools available to manage my email identity and aliases.

> 

> They don't exist because everybody else uses aliases, forwarders,

> plus-addressing, etc. for an account. This has the added benefit that

> it scales for multiple accounts in the same domain.

 

Agreed, but aliases & forwarders & plus-addressing are not as good.  (Well, 
plus addressing could be ideal if only it didn’t have some problems, just as 
the catchall could be ideal if it didn’t have an equal set of problems.)  The 
main obstacle to the catchall idea is the assumption that the domain boundary 
delimits the organization boundary.  In an organization, if all they do is 
email, then there's no problem having more than one domain, or even having a 
separate subdomain for every user in the organization.  The place where the 
problem arises for personal subdomains is when a you create a new user, there 
is no facility to instantly and automatically create a new dns MX entry for 
every new user, and when your exchange server (or whatever) distributes the 
corporate addressbook & shared calendar only to a single domain.  Stuff like 
that.

 

There's no technical boundary; they could implement these things differently if 
they wanted to.  It's just not the way things are built now.

 

 

> Seems to me that if you really want to change the way email behaves,

> then you should think about writing an RFC.

 

Agreed again.  This is why I refer to myself as "blowing steam" on this 
subject.  I know it will never be.  I just think it's a good idea, and I like 
talking about it, however hopeless it may be.  Anything which makes you think 
about a subject more makes you smarter.  I would not have known of plus 
addressing, if it weren’t for the responses to my original post.  Never heard 
of plus addressing until a few days ago.

 

The main reasons why I don't bother writing an RFC about this are:

·         I can’t spare the time to complete the project.  Even in the simple 
case of just a milter in sendmail or whatever.  I have a job and a career, and 
I need to focus on things that I get paid for.

·         Best case scenario, people get free and permanent antispam.  It hurts 
the antispam industry and spammers alike.  So I’ve created enemies, and no 
friends.  When “having no problems” becomes standard, people generally take it 
for granted, and give no thanks.

·         Whoever wants to join the cause ... aid in development ... they’ll 
have the same obstacles as me.  A promise of hard work, no pay, and no glory.  
You might become a target for damaging attacks.  Nobody wants to do work like 
this.

_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to