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.Admin wrote: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...
There would be the possibility to create new domain names for this. Like trashmail1.net, trashmailN.net...Z wrote: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.Admin wrote: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...
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.
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. ;(Admin wrote:There would be the possibility to create new domain names for this. Like trashmail1.net, trashmailN.net...
Yes, its a great solution.Z wrote: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. ;(Admin wrote:There would be the possibility to create new domain names for this. Like trashmail1.net, trashmailN.net...
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.
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:Admin wrote:If the database server would be slow, then also all smtp frontend servers.
Do you have a solution for this problem?
Its a nice idea to use cached servers. It must be guaranteed that the cache servers are synchronized.Z wrote: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:Admin wrote:If the database server would be slow, then also all smtp frontend servers.
Do you have a solution for this problem?
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.
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.Admin wrote:Its a nice idea to use cached servers. It must be guaranteed that the cache servers are synchronized.
I'm not sure if I understand the positive and negative hitlists.Z wrote: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.Admin wrote:Its a nice idea to use cached servers. It must be guaranteed that the cache servers are synchronized.
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?
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.Admin wrote: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?