Here's very simple TCP proxy that seems to be working ok with SMTP. I'm sure there are also better options, this was simple and written in Python, so I could check it's source before installing and running it.
I tried it just to prove my point. Now I have alternate IP address on s.sami-lehtinen.net for trashmail.net, which I can use with my own domain names, and nobody knows that mails are actually handled by TM.

Saxtus wrote:Then how about using custom trashmail MX server that you provide (possibly with different IP than the one used to serve the trashmail.net addresses, to avoid the blacklists), as I have access to DNS records?

I don't know if I am allowed to disclose the rival service that I am using,
but they do exactly that (even for non-paying users) and so far it seems that works just fine.

The bad thing is that they don't have blacklist/whitelist system, nor challenge-response system (as they are against it).

There are two solutions is:
1. You get a Linux dedicated or virtual server
2. I rent the dedicated or virtual server for you

At Hetzner.de the smallest minimum VPS would costs 94.8 EUR per year.
There is no other solution to get an own IP for less costs as I know.

Thank you for sharing your market research, I really appreciate it, but I was talking about using a secondary IP that you will use for all of your customers, not an IP for each customer,
with "possibly" the significant keyword: I.e. you can still be using your current IP to host your MX server instead of customers to host it.

It's just an idea of course, based on the working solution from the other service I was talking about.
Now that I think about it, probably you knew about them, so me bringing it up, was a bit redudant and offensive.
Apologies.

I am trying to contribute ideas for a better trashmail because I love the service
and I hate seeing what is happening to it right now (as I've explained at original post).

I would simply get secondary IP from the current provider and forward it to the main server using lxc or even directly configuring at it as secondary interface for the server. Simply leaving out clear reverses / dns configs, which would immediately reveal where it's "linked to" + have some "random" domain name with whois guard. Don't transfer old "dirty" domains, get new clean ones.

Z wrote:I would simply get secondary IP from the current provider and forward it to the main server using lxc or even directly configuring at it as secondary interface for the server. Simply leaving out clear reverses / dns configs, which would immediately reveal where it's "linked to" + have some "random" domain name with whois guard. Don't transfer old "dirty" domains, get new clean ones.

Even LXC is overkill for only a tcpproxy app.
Better would be to run it on the root node and protect it via apparmor.

Ok we will do the following:
1. Buying a new domain name using a Registrar which supports WhoisGuard
2. Renting two VPS services (one for the incoming emails, one for the backup MX server)
3. Using a TCP proxy to redirect the incoming connection to trashmail.net

This new domain name will be available only for TrashMail Plus members, and hidden for all other non-plus members.
If you have suggestion about how should look the new domain name, please send me an email to contact@ferraro.net.
I think the best would be a serious looking domain name, that nobody guess its a DEA service behind there.

I'm running a traditional mail server. The software I use makes it straightforward to add aliases to the user database. I'd be tempted to grab the FireFox add-on and modify it so that aliases are added to my server directly, bypassing TrashMail. However, that has the disadvantages that I'd have to upgrade the add-on on each and every FF release, and roll my own server-side stuff from scratch. (BTW, replying works very well in ThunderBird with the Virtual Identity add-on.) OTOH, extending the add-on or the protocol would add complications, but can result in more momentum for TM and disposable addresses in general. I imagine it could work like so:

The add-on could be configured to use normal user's credentials to log-in at the user's mail server,

the server should be able to check the generated address, possibly adding a prefix, e.g. XX-875239756@mydomain.tld, to ease filtering,

when mail arrives, a mail filter on the server can generate local redirections to the user's folder,

IMAP users should be able to specify a sub-folder, along with behavior options (e.g. lifetime) and comments, when they generate new addresses.

I believe any decent postmaster on a modern server can comply with that.

What would be the role of the TM server, then? It can accomplish various features. For example, there can be managed installations, where the filter looks up TM during the SMTP transaction, in order to learn what to reply. In user-centric installations, TM can collect a user's disposable addresses from different domains. In data-sharing installations, TM could monitor which organizations tend to disclose, leak, or improperly use the addresses of their customers. (As a side note, I hate challenge response system. I'd rather check that if an address was given to a given organization only, it does not receive mail from different organizations.)

An additional feature would be to cooperate with well-behaved senders. In addition to the website, they should pass a List-Id or similar identifier by which their mail can be identified (through DKIM or similar signatures).

I'm running a traditional mail server. The software I use makes it straightforward to add aliases to the user database. I'd be tempted to grab the FireFox add-on and modify it so that aliases are added to my server directly, bypassing TrashMail. However, that has the disadvantages that I'd have to upgrade the add-on on each and every FF release, and roll my own server-side stuff from scratch. (BTW, replying works very well in ThunderBird with the Virtual Identity add-on.) OTOH, extending the add-on or the protocol would add complications, but can result in more momentum for TM and disposable addresses in general. I imagine it could work like so:

The add-on could be configured to use normal user's credentials to log-in at the user's mail server,

the server should be able to check the generated address, possibly adding a prefix, e.g. XX-875239756@mydomain.tld, to ease filtering,

when mail arrives, a mail filter on the server can generate local redirections to the user's folder,

IMAP users should be able to specify a sub-folder, along with behavior options (e.g. lifetime) and comments, when they generate new addresses.

I believe any decent postmaster on a modern server can comply with that.

What would be the role of the TM server, then? It can accomplish various features. For example, there can be managed installations, where the filter looks up TM during the SMTP transaction, in order to learn what to reply. In user-centric installations, TM can collect a user's disposable addresses from different domains. In data-sharing installations, TM could monitor which organizations tend to disclose, leak, or improperly use the addresses of their customers. (As a side note, I hate challenge response system. I'd rather check that if an address was given to a given organization only, it does not receive mail from different organizations.)

What do you think?

Using its own server is better to have the full control. The only solution I see for that would be to install a full clone of TrashMail.net with its complete API. I was thinking already about that to propose this as business solution.
How much would you pay for it? How would you install such a solution. Would be an ISO live CD or VMWare image a good solution for it? It would be better to isolate such a system from other services.

I have the same problem with Wunderlist Todo List tool. I would like to use it with my own server, but it uses their dedicated servers.

Ale wrote:An additional feature would be to cooperate with well-behaved senders. In addition to the website, they should pass a List-Id or similar identifier by which their mail can be identified (through DKIM or similar signatures).

Admin wrote:
Using its own server is better to have the full control. The only solution I see for that would be to install a full clone of TrashMail.net with its complete API. I was thinking already about that to propose this as business solution.
How much would you pay for it? How would you install such a solution. Would be an ISO live CD or VMWare image a good solution for it? It would be better to isolate such a system from other services.

I don't charge for hosted mailboxes, so I'm unable to tell a price. I'd love an open source software to install on my server, but then I'd still have to modify it in order to suit my mail server configuration. I'd agree that a full clone is the most straightforward possibility to get full control, but I'm not sure that's the only way.

The FireFox add-on is the most valuable item, from my point of view, and it is already open source. I could pay a tiny donation for modifying it, as it would be wastefult to maintain multiple forks. Besides the ability to configure the server address, I think it would be interesting to develop a protocol change that I'll try and describe in the following paragraphs.

I found that disposable addresses are considered somewhat fraudolent by spammers: see "Spam Trap Suppression" in http://www.towerdata.com/email-validati ... -cleaning/. They ought to change their mind. It is also interesting that they prefer heuristics over confirmed opt-in (COI), that stance may put them in trouble when Canada will enforce their anti-spam law, next summer. One reason to skip COI is that users have been instructed never to click on a link received in an email message. A tool like the FF add-on, which has already authenticated the user, could ascertain the user's will to subscribe, and certify that by sending a digitally signed confirmation. In order to enable that behavior, spammers would have to upgrade their web forms. The form should somehow lead to the URL where the confirmation has to be posted, and possibly more data describing the verifiable characteristics of the mail stream that is being authorized. Also, there should be a way to get the same behavior in case the user didn't install the add-on; for example, they could include the relevant javascript.

I doubt that spammers will enthusiastically adhere. Yet, that looks like a reasonable attempt at distinguishing "cooperative spammers" from opponents. I'm not enough business-oriented to devise how an organization can earn some money out of that scheme, but there must be multiple ways to do it. I posted a few messages on this topic to the ASRG, which moved from IRTF to http://lists.services.net/cgi-bin/mj_ww ... extra=asrg --it's quicker than this forum, as it took me weeks to find out you replied, but I'm not in a hurry

Ale wrote:An additional feature would be to cooperate with well-behaved senders. In addition to the website, they should pass a List-Id or similar identifier by which their mail can be identified (through DKIM or similar signatures).