Spam really increased

[Admin]

The average spam rate is now above 250 mails per minute.
I just saw over 600 spams per minute. Its interesstings it grow up and up...

[Z]

The average spam rate is now above 250 mails per minute.
I just saw over 600 spams per minute. Its interesstings it grow up and up...

I really hope that you won't encounter same problem as so many other temp email address services have encountered. Over time (a few years) spam traffic has grown to so huge dimensions that their server really can't handle it. And they would need smtp server farm to take care of all that (junk) traffic.

As you mentioned costs. It's not a cheap solution and that's why some of services like this are out of business.

I wish TrashMail very good luck.

Some services have also encountered clear DoS. attacks. Thousands of open SMTP sessions transmitting data really dog slowly.

[Admin]

The average spam rate is now above 250 mails per minute.
I just saw over 600 spams per minute. Its interesstings it grow up and up...

I really hope that you won't encounter same problem as so many other temp email address services have encountered. Over time (a few years) spam traffic has grown to so huge dimensions that their server really can't handle it. And they would need smtp server farm to take care of all that (junk) traffic.

As you mentioned costs. It's not a cheap solution and that's why some of services like this are out of business.

I wish TrashMail very good luck.

Some services have also encountered clear DoS. attacks. Thousands of open SMTP sessions transmitting data really dog slowly.

There would be the possibility to create new domain names for this. Like trashmail1.net, trashmailN.net...

[Z]

There would be the possibility to create new domain names for this. Like trashmail1.net, trashmailN.net...

Unfortunately it doesn't solve the problem for those unlimited/unlimited paying customers. Who really expect to have their email address constant even in future. ;(

That's the reason why most of services doesn't do that kind of changes. Best solution is simply have server which can handle enough smtp sessions. I suggested some service providers that they would use frontend servers. Which only accept sessions and check if address is valid. If yes, they'll store the data and forward it to mainserver. Which takes care of rest of processing and forwarding. But there is just that problem, it'll require multiple servers and that adds quite much to cost.

[Admin]

There would be the possibility to create new domain names for this. Like trashmail1.net, trashmailN.net...

Unfortunately it doesn't solve the problem for those unlimited/unlimited paying customers. Who really expect to have their email address constant even in future. ;(

That's the reason why most of services doesn't do that kind of changes. Best solution is simply have server which can handle enough smtp sessions. I suggested some service providers that they would use frontend servers. Which only accept sessions and check if address is valid. If yes, they'll store the data and forward it to mainserver. Which takes care of rest of processing and forwarding. But there is just that problem, it'll require multiple servers and that adds quite much to cost.

Yes, its a great solution.
Except for the costs, how do you handle the problem that the email servers in the front checks the address?
You need a central database which contains all existing trashmail email addresses to check if an email address exists or not. How do you check that? With one database server? If yes, then you move hardware resource problem to the database server.
If the database server would be slow, then also all smtp frontend servers.
Do you have a solution for this problem?

[Z]

If the database server would be slow, then also all smtp frontend servers.
Do you have a solution for this problem?

There is no reason what so ever, why database lookups would be that slow. But if that's the problem. Like you're using some old junk as database server or indexes are missing etc. Then you could do following:

During every lookup to main database. After check hash address, add statusbit as data and store it to local binary tree cache. After that checking addresses is lightning fast. There is no problem checking 1 million addresses / second. In most cases problem is handling smtp (tcp/ip) sessions or updating databases with huge indexes. Not reading from those.

In case of something important changes at main db, send notification to cache servers to update status. If that's really needed. Like in case of new address creation. Win ok changes to fail, notification doesn't really matter because message is anyway discarded in process later. But if that's important it could also notify frontend servers.

Some reading for you: http://www.slac.stanford.edu/BFROOT/www ... CIDR05.pdf

I often wonder how some processes can be so darn slow, even computers are very fast. In most cases reason is very simple. Moronic desing or extremely bad implementation. There are plenty of ways to totally ruin performance. If you're not thinking at all when you're planning something. And that's very common. "It just works". Yeah, but there will be major performance issues. I wonder how google would work if they wouldn't do any optimization, caching etc at all.

[Admin]

If the database server would be slow, then also all smtp frontend servers.
Do you have a solution for this problem?

There is no reason what so ever, why database lookups would be that slow. But if that's the problem. Like you're using some old junk as database server or indexes are missing etc. Then you could do following:

During every lookup to main database. After check hash address, add statusbit as data and store it to local binary tree cache. After that checking addresses is lightning fast. There is no problem checking 1 million addresses / second. In most cases problem is handling smtp (tcp/ip) sessions or updating databases with huge indexes. Not reading from those.

In case of something important changes at main db, send notification to cache servers to update status. If that's really needed. Like in case of new address creation. Win ok changes to fail, notification doesn't really matter because message is anyway discarded in process later. But if that's important it could also notify frontend servers.

Some reading for you: http://www.slac.stanford.edu/BFROOT/www ... CIDR05.pdf

I often wonder how some processes can be so darn slow, even computers are very fast. In most cases reason is very simple. Moronic desing or extremely bad implementation. There are plenty of ways to totally ruin performance. If you're not thinking at all when you're planning something. And that's very common. "It just works". Yeah, but there will be major performance issues. I wonder how google would work if they wouldn't do any optimization, caching etc at all.

Its a nice idea to use cached servers. It must be guaranteed that the cache servers are synchronized.

[Z]

Its a nice idea to use cached servers. It must be guaranteed that the cache servers are synchronized.

With proper caching and B-tree you can also run this process with 16 threads with 8 cores. And all threads run with almos full speed.

I don't agree with ou that those need to be synchronized.

With positive cache hitsk. There is no need to change status from positive to negative, it really doesn't matter. Status changes when cache is flushed. If required also expiring accounts can be updated to cache trough notification.

With negative cache hits. Account management server can notify cache servers that address XXX is being used and cache server check that it's not on negative list. This happens so rarely that it doesn't affect performance at all.

Cached servers aren't "synchronized or realtime". All signaling is assynchronous and doesn't block any processing. If B tree updates are done correctly also internal cache blocking can be minimized. And data can be accessed by several cores even notification thread is making updates. I often notice that people are asking for "synchronized or realtime" stuff, but in most of cases it's sure way to ruin performance. If assynchronous and non-blocking operations are allowed, it'll give hugely better performance.

No it's not real time or synchronized. It might take a 20 ms to update information. Is that too bad?

[Admin]

Its a nice idea to use cached servers. It must be guaranteed that the cache servers are synchronized.

With proper caching and B-tree you can also run this process with 16 threads with 8 cores. And all threads run with almos full speed.

I don't agree with ou that those need to be synchronized.

With positive cache hitsk. There is no need to change status from positive to negative, it really doesn't matter. Status changes when cache is flushed. If required also expiring accounts can be updated to cache trough notification.

With negative cache hits. Account management server can notify cache servers that address XXX is being used and cache server check that it's not on negative list. This happens so rarely that it doesn't affect performance at all.

Cached servers aren't "synchronized or realtime". All signaling is assynchronous and doesn't block any processing. If B tree updates are done correctly also internal cache blocking can be minimized. And data can be accessed by several cores even notification thread is making updates. I often notice that people are asking for "synchronized or realtime" stuff, but in most of cases it's sure way to ruin performance. If assynchronous and non-blocking operations are allowed, it'll give hugely better performance.

No it's not real time or synchronized. It might take a 20 ms to update information. Is that too bad?

I'm not sure if I understand the positive and negative hitlists.
Here is a real example: 99% of incoming emails are no more existing trashmail accounts.

1x email comes to a Cache Server. The cache server checks now in its local database if this name of email address is known. If not, email is rejected. If yes then email is forwarded to the real trashmail.net smtp server.

When you delete a trashmail account, you need first to delete it on the real database, then later on the cache server.
Is this correct?

[Z]

When you delete a trashmail account, you need first to delete it on the real database, then later on the cache server.
Is this correct?

Yes. But as I mentioned. But it depends from situation if it's required at all. Dying accounts are such a small part of overall accounts that I don't know if it's required to notify servers. But there isn't any real reason either why not to notify, because it's also very small task. If cache servers are "uptodate" we can skip this check on main server. But if updating counters etc values is done on main server anyway, that database record needs to be accessed anyway and updated.

I didn't specify how often cache would berefreshed or flushed. But I also think that because mainserver still needs to do that check if account is really still active, it really doesn't matter if some "false positive" messages come trough to server. It means that positive -> negative translation notifcation isn't needed.

Those cache frontend servers will anyway pick those 99.9% of messages which are coming for non-existing or dead accounts. And even larger number of incoming tcp/ip connections which aren't smtp sessions at all SYN flood, slow hanging tcp/ip sessions to fill tcp/ip pool with these to prevent real smtp sessions getting trough etc. These two are the real problem at least with some other servers.

There is anyway no reason what so ever. Why this kind of cached frontend can't sit on same server and answer to if account exists queries instead of using database everytime. But I don't really understand how database nowadays would be so slow it can't answer to simple queries like these. That cached b-tree option is just "extreme" solution. I don't think it's really needed.