Domain Aliases on Enhanced Account Limitation

[arthurdent]

I am a fastmail user for over 4 years now and was pleased when you upped the hosted domains to 50 but the limitation of 200 virtual domain aliases could be limiting feature and needs to be increased.

If I was to add all of my 30 plus domains as virtual domains then added commonly used aliases (wildcarding encourages spammer header forging) 200 virtual domain aliases would be quickly reached.

eg: sales, support, accounts, admin, management, members, affiliates, partners for each domain would exceed the 200 limit quickly as 8x30 is 240 virtual domain aliases and that does not allow for personalised aliases like my name or nickmame.

A more realistic limit would be 1000 as that allows 10 aliases per virtual domain and as some would be more and other less but that should be more than adequate.

[Merovingian]

A 4-year user of fastmail, and only posting now? I'm guessing you have had very little issue with fastmail

Welcome to the EMD Forums, arthurdent!
and good suggestion.

[hadaso]

Manually entering all these hundreds of aliases is a lot of work. Also perhaps if lots of people did it it might result in huge alias tables in FastMail's servers?

I think that a better solution for blocking generic addresses on many domains would be to allow blocking by matching the recipient address with a pattern.

Now to half an idea of how to block generic addresses without manually creating many aliases for many domains: perhaps it can be done by creating for many domains a catchall alias that is targeted at *@certaindomain and then defining the aliases to be blocked only for this domain (and targeting them at themselves so they would be rejected). EG *@a.tld targets *@g.tld, and then sales@g.tld targets sales@g.tld. Then sales@a.tld would resolve to sales@g.tld which would be rejected because it doesn't resolve. (another approach is to make sales@g.tld an inactive alias, but self targeting allows it to be rejected even when a catchall exists for g.tld).

[arthurdent]

Merovingain,

Yes the only problem I have had in 4 years is server crash about 15 months ago so the fastmail service is more reliable than 99% of hosting companies I have dealt with over the last 12 years.

Hadaso,

The spoofing of my domains has only happened when the mx records were changed to fastmail and only since mid November. You will need to explain a bit better what you mean and I may try using custom sieve settings (but I will need to read the sieve docs) to eliminate the need for all the virtual domain aliases.

[hadaso]

Originally Posted by arthurdent

You will need to explain a bit better what you mean and I may try using custom sieve settings ...

Actually I was not talking about Sieve at all.

In the virtual Domains screen the top screen defines the virtual aliases. Each alias has a target.
I have *@hadas0.c0m target *@hadas0.n3t
I have *@hadas0.n3t target somthing like username+mydomain.*@fasrmail,fm
and I have bounce@hadas0.n3t target bounce+bounce@hadas0.n3t

so mail sent to bounce@hadas0.c0m resolves to bounce@hadas0.n3t which then resolves to bounce+bounce@hadas0.n3t (which resolves to baounce+bounce.bounce@hadas0.n3t which resolves to ...) and eventually loop detection or overflow detection makes it fail so it doesn't resolve at all and the sending SMTP client receives an error message saying the address does not exist. (bounce@hadas0.n3t targets bounce@hadas0.n3t would have worked OK for this). But random@hadas0.c0m would resolve to random@hadas0.n3t which would then resolve to username+mydomain.random@fastmail.fm and would be delivered to my Inbox or to folder mydomain.random (if it exists) unless some Sieve filtering rule does something else with it.

The main point was that if you use all the domains the same way you can use targeting of *@onedomain to *@otherdomain and then only on "otherdomain" define the aliases you want to to do something with and target them to your username if you want to receive mail for them (and to themselves if you want to have a catchall but have selected localparts bounce).

[beq]

Originally Posted by hadaso

... allow blocking by matching the recipient address with a pattern.

FYI I saw that Lavabit advertises this capability:

http://lavabit.com/features.html

Originally Posted by Lavabit

Whitelisting
... The Lavabit e-mail server allows users to configure regular expressions that are then compared to a sender’s address. If a match is found, the message is allowed through. ...

Blacklisting
Our e-mail server supports using regular expressions to block unwanted e-mail at the server. If a message matches a provided regular expression, the server can be configured to mark the message as 'SPAM', delete it or bounce the message back to the sender with an explanation.

I had a free account from the Nerdshack days, but whitelisting/blacklisting is only available for Lavabit's $8/yr and $16/yr paid accounts. Sounds interesting though and I'm tempted to try (I understand they've just released code supporting IMAP, and Squirrelmail webmail and eventually custom webmail will be coming next year).

Originally Posted by hadaso

... creating for many domains a catchall alias that is targeted at *@certaindomain and then defining the aliases to be blocked only for this domain ...

Good idea, works for me at FM.

Strange thing is that I thought this has been working for me at Tuffmail too, but I just retested and it (no longer?) works. I define a reject adress in domain1, and have domain2 forward to domain1. But mail sent to reject@domain2 doesn't get rejected at the RCPT TO stage as expected.

[hadaso]

Originally Posted by beq

FYI I saw that Lavabit advertises this capability:

What I saw advertised there is regexp matching to sender's address, not recipient.

What I want to have in Fastmail is regexp (or some other pattern matcing) for the recipient address, which can replace the definition of multiple aliases just for blocking them (though being able to block by matching both recipient and sender would be better as it would allow creating a "channel": an email address that receives only from particular senders and rejects all others at SMTP).

[arthurdent]

I am testing a custom sieve config that only delivers legitimate mail using a combination of custom spam, bayes data, ip origin matching and so far it is working and I will see what happens when the world is over the festive season.

The process I am testing extends spam detection using x-spam-hitsintroducing bayes rejection and rearranging the sieve script so non specified mail or bounces from forged email addresses just falls through and is rejected..

So far so good as I have wildcarded the virtual domain aliases again today!

[mikev99]

Originally Posted by hadaso

Actually I was not talking about Sieve at all.

In the virtual Domains screen the top screen defines the virtual aliases. Each alias has a target.
I have *@hadas0.c0m target *@hadas0.n3t
I have *@hadas0.n3t target something like username+mydomain.*@fasrmail,fm
and I have bounce@hadas0.n3t target bounce+bounce@hadas0.n3t

so mail sent to bounce@hadas0.c0m resolves to bounce@hadas0.n3t which then resolves to bounce+bounce@hadas0.n3t (which resolves to baounce+bounce.bounce@hadas0.n3t which resolves to ...) and eventually loop detection or overflow detection makes it fail so it doesn't resolve at all and the sending SMTP client receives an error message saying the address does not exist. (bounce@hadas0.n3t targets bounce@hadas0.n3t would have worked OK for this). But random@hadas0.c0m would resolve to random@hadas0.n3t which would then resolve to username+mydomain.random@fastmail.fm and would be delivered to my Inbox or to folder mydomain.random (if it exists) unless some Sieve filtering rule does something else with it.

Would not it be easier for the FM system to just allow one to have a recipient reject list for virtual domains and FM aliases?

[hadaso]

Originally Posted by mikev99

Would not it be easier for the FM system to just allow one to have a recipient reject list for virtual domains and FM aliases?

Of course it would be easier. Before posting the first time about the use of infinite loop in alias resolution to make it bounce (and before trying it) I asked Rob if it is OK and here is his reply:

On Mon, 6 Nov 2006 Robert Mueller said:
> It's ok, there's a circular reference check in the code already
>
> The interesting thing is that it does do what you want, makes the address not
> resolve. I wouldn't use that as a feature though to be honest. We should just
> add the ability to have a "reject" target.

This was following some discussion where he also told me about some simplifications they were thinking about for the alias targeting, such as having a "self" target that users use instead of targeting the username. At the time I collected some ideas about possible related functionality and put it here on the wiki (and also started a thread to discuss it. There's a link from the wiki page).