disposable email prefixes for existing mailboxes

[wu-lee]

I am considering switching an existing Exim mailserver for a Cloudron instance.

One feature I need to maintain is a custom mail routing rule which allows mailbox addresses with an arbitrary prefix, designed to implement disposable addresses for use as casual log-ins, inspired by spamgourmet.org.

Is this possible with the default Cloudron mail service? Perhaps using some custom configuration, for instance, can SpamAssassin rules do this?

Thanks!

---

I'll explain the use-case in more detail briefly.

I might have a mailbox alice@example.com, and an alias for this, bob@example.com, which by itself doesn't accept mail, but will forward mail to alice@example.com when prefixed with any arbitrary word (delimited by dot). For example, twitter.bob@example.com, yahoo.bob@example.com and ebay.bob@example.com would all forward to alice@example.com by default, as well as any other prefixed address you could think of.

This allows unique email aliases like this to be invented off-the-cuff when creating a log in for a site requiring an email address to register a user account. These addresses can be disabled if and when they start attracting spam (perhaps because the site has been penetrated by malware, and the user data captured and redistributed in spammer databases).

Because they are unique, the addresses also tends to reveal the source of a breach, because the prefix indicates what it was used for originally.

Disabling an address is done by alice@example.com sending an email to one of her aliases with the subject !off, via an authorised connection to the SMTP server implementing the prefix aliases.

If switching to another implementation, the mechanism for managing these aliases could change, but I'd need the addresses to continue working, obviously.

[jdaviescoates]

@wu-lee I'm not sure if this is possible on Cloudron or not, but I like it.

Saying that, I already do something similar just by using the + sign e.g. me+someservice@mydomain.coop which is supported by Cloudron, see https://docs.cloudron.io/email/#subaddresses for more info.

[wu-lee]

@jdaviescoates - this is close, but not quite a cigar, because although this would work when just starting to use this scheme, there's a whole bunch of existing addresses in use using a different scheme.

I think Cloudron's SMTP server is Haraka, correct? Is it possible to install plugins for it this context? (I might be able to write a plug-in.)

[girish]

The closest as mentioned is the subaddressing, though I understand your point about existing addresses following a different scheme.

SpamAssassin rules only help in categorizing spam and cannot change email delivery. How do your current filters look like? Is it like if it's like *.bob then route it to a specific mailbox ?

As a thought, if Cloudron's current aliases supported wildcard, would it help your setup?

[privsec]

After reviewing this thread, it sounds almost like the wildcard addressing would be perfect. another potential solution, would be implementing Anonaddy

[wu-lee]

@girish, yes - the implementation rules are logically "like *.bob then route it to a specific mailbox", but there is extra logic to handle things like:

• if the alias is marked disabled, drop it
• if the subject is !off and the connection is authenticated as the user in question, disable the alias and drop it
• ...plus some similar things (implementing !on and !report functions)

State needs to be stored somewhere (the implementation uses a SQLite3 DB). So if the wildcard alias plugin does not store state, that probably won't do it.

Implementing this in Exim filter rules is challenging, both to write and to read, but FWIW it's here

[girish]

@wu-lee I see. So, I think supporting arbitrary plugins in haraka, while possible, will be quite complicated for us. This is because we have a complicated Haraka plugin ourselves and there is node versioning etc which we update based purely based on our internal tests without thinking about external users. So, I am going to try to avoid it, if possible.

For your use case:

• Let's say cloudron supported wildcard aliases. Like *.bob@ is added an alias to allbobs@
• You can then add sieve rules in allbobs@. Sieve supports inspecting subject, dropping messages, forwarding, archiving/keeping a copy etc. Essentially, it will give us the "programming" language that is needed.

Do you think the above will be enough ? I am not a sieve expert myself. https://protonmail.com/support/knowledge-base/sieve-advanced-custom-filters/ and https://www.fastmail.help/hc/en-us/articles/1500000280481-Sieve-scripts give a good overview.

[wu-lee]

@girish I've written non-trivial Sieve filters before, Dovecot supports it (which the server in question uses, and I believe, Cloudron). So far as I know (and scanning through the extensions in those docs) it doesn't really support storing state between filter runs which will allow aliases to be disabled.

So I think the best I could hope for is to use wildcard aliases, and manually block spammy ones using sieve filters. This wouldn't be very user friendly, so this seems to be a potential show-stopper.

(Possibly something external to Haraka could be inserted into the mail delivery process?)

Thanks!

[girish]

I will move this to Feature request then.