Eaten option

General discussion re sg.

Eaten option

Postby habibie » Fri Dec 16, 2011 12:49 pm

What exactly does the EATEN option do? Does it take the incoming spam e-mails and send them to /dev/null or reject them?
habibie
 
Posts: 16
Joined: Sat Dec 10, 2011 1:27 am

Re: Eaten option

Postby gourmet » Thu Jan 05, 2012 8:38 am

habibie wrote:What exactly does the EATEN option do? Does it take the incoming spam e-mails and send them to /dev/null or reject them?


Spamgourmet "never" bounces, because there are a few exceptions. Normally when email gets eaten it's sent to /dev/null, sender is not notified.
gourmet
 
Posts: 124
Joined: Thu Mar 27, 2008 4:46 pm

Re: Eaten option

Postby habibie » Sun Jan 15, 2012 2:34 am

gourmet wrote:
habibie wrote:What exactly does the EATEN option do? Does it take the incoming spam e-mails and send them to /dev/null or reject them?
Normally when email gets eaten it's sent to /dev/null, sender is not notified.
That's really bad because spammers won't know and keep sending spam e-mails to waste (Internet) resources.

I have been using EndJunk services for a long time. When any spammer sends me junk e-mails to one of my EndJunk alias/external e-mail accounts, I just click the Disable option to block further incoming junk e-mails from such a spammer. Not only I won't receive any further junk e-mails, but they get rejected. When I re-enable such an alias/external e-mail account in a few days (perhaps a week or so), no more incoming junk e-mails.
habibie
 
Posts: 16
Joined: Sat Dec 10, 2011 1:27 am

Re: Eaten option

Postby gourmet » Mon Jan 16, 2012 5:36 pm

habibie wrote:
gourmet wrote:That's really bad because spammers won't know and keep sending spam e-mails to waste (Internet) resources.


Real spammers won't ever care about bounces, so that point isn't valid anyway. But it's actually worse for legimate senders, because they would stop sending their stuff is messages would bounce.

Also these legimate messages keep using SG's bandwidth, even messages won't be forwarded.

--
http://www.sami-lehtinen.net/
gourmet
 
Posts: 124
Joined: Thu Mar 27, 2008 4:46 pm

Re: Eaten option

Postby habibie » Mon Jan 16, 2012 9:44 pm

gourmet wrote:
habibie wrote:
gourmet wrote:That's really bad because spammers won't know and keep sending spam e-mails to waste (Internet) resources.
Real spammers won't ever care about bounces, so that point isn't valid anyway.
I strongly disagree with what you said above even though I had that thought before.

While lurking through the Internet a few years ago, I discovered someone mentioned on how to fight spammers using a dynamic DNS with a local MTA, i.e. sendmail. So, I went ahead to implement such a scheme bysetting up my own e-mail address using a BSD SendMail on my Linux machine with a DynDNS service. This way, I could easily expose my e-mail address to spammers using an FQDN instead of an IP Address. Immediately, I started to get 100+ spam e-mails/hour on my Linux machine. Then, I login into my DnyDNS account and configure my FQDN so that it pointed to 127.0.0.1. I left this setting for a couple of days then reverted back to my IP Address to find out no more incoming spam e-mails. I bet you the admin of such spammers MTA were overwhelmed by a round-robbin bouncing e-mails! If spammers could careless about bounced e-mails, then why my Linux machine no longer received spam e-mails once I reactivated them from a few days of redirection to 127.0.0.1? This also happens with my disposable e-mail addresses from my EndJunk account. Once I reactivated (enabled) after a few days of being disabled, no more incoming spam e-mails.

Also these legimate messages keep using SG's bandwidth, even messages won't be forwarded.
Honestly, I don't see it. In order for the spam e-mails to be eaten by SG, they must have been arrived @SG MTA server to waste SG's Internet bandwidth. If SG rejects the spam e-mails, then the only wasted bandwidth is the rejection messages sent to spammer MTA server from SG. So, why waste resources to eat the spam e-mails, if SG can be configured just to reject the spam e-mails (which doesn't take any resources but to reject), AFAICT.
habibie
 
Posts: 16
Joined: Sat Dec 10, 2011 1:27 am

Re: Eaten option

Postby gourmet » Tue Jan 17, 2012 6:38 am

habibie wrote:Immediately, I started to get 100+ spam e-mails/hour on my Linux machine. Then, I login into my DnyDNS account and configure my FQDN so that it pointed to 127.0.0.1. I left this setting for a couple of days then reverted back to my IP Address to find out no more incoming spam e-mails.


I really really wish it would be so simple. In that case these statistics should really be quite different. ( 163 spam mails/min, 273 431 908 totally rejected since july 2007 ) And yes, they did receive bounces, and junk just keeps coming in.

habibie wrote:So, why waste resources to eat the spam e-mails, if SG can be configured just to reject the spam e-mails (which doesn't take any resources but to reject), AFAICT.


That's one thing I can completely agree with you. As I said earlier, eating consumes more resources than bouncing. But that's just how the SG has been working all the time, and does work in future. Point is not to bounce, and inform that address isn't active anymore. There are other services that do bounce.

Btw. If bouncing would stop spam coming from in, then it should be really beneficial to block spam by bouncing. Unfortunately that clearly isn't working solution because it isn't being widely used. Services like gmail and other big businesses would benefit enormously from it.
gourmet
 
Posts: 124
Joined: Thu Mar 27, 2008 4:46 pm

Postby josh » Tue Jan 17, 2012 4:17 pm

In order to deal with a couple of actual DOS attacks, and also with legions of spambots, we implemented a strategy that does result in bouncing (sort of) for what turns out to be the vast majority of attempted sends - when our software detects what looks like a bot, we IPTable the IP address into nilspace for a little while. This is the most bandwidth friendly approach of course - simply drop all packets. The sending mail server (likely to be a compromised user box) can't make a connection at all, which would result in a bounce message originating at the sending server, if it were properly configured -- we have to assume that the bots are not, of course.

Because of this, our global stats are not accurate - we reject a *FAR* greater number of messages than those which make it to the code that records them in the database upon which the stats are based. On the other hand, stats on a per user basis are probably accurate - bots aren't generally trying to send to individual users, but rather are using the "Rumpelstiltskin" or dictionary approach to blasting out messages.

For "legitimate" connection attempts - that is, attempts to send to what appears to be a valid disposable address, whether or not it has any messages, our philosophy has been to quietly ignore messages that are "eaten". There are a number of reasons for this, both technical (i.e., our main code base doesn't hook into the SMTP dialog early enough for a clean bounce), and practical - (e.g., it's nice to let a retailer's address expire after the holidays, then re-enable it a year later so you can do some online shopping without worrying about the retailer having de-activated your account due to bouncing).

As for whether real, active spammers take the time to cull their databases of bounced addresses, I can only speculate. I do believe they would have an incentive *not* to cull, though - if they're selling their dubious services to unsuspecting small business types, they'll do better to say they have a larger database of addresses - removing invalid addresses would reduce that.

More above-board services, such as constant contact, do cull, I'm sure, but their users are more likely to fit the legit-but-chatty retailer whom we like to silence for months at a time, then resume communication with.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby habibie » Wed Jan 18, 2012 2:41 pm

I am a new SpamGourmet user and have not yet encountered any incoming spam e-mails yet. So, I wouldn't really know if it would be able to completely stop further incoming spam e-mails once a temporarily disabled disposable e-mail address has been re-enabled. For one thing that I know is my experiment using my own MTA server, i.e. sendmail on a Linux machine behind a NAT/Firewall router with port 25 forwarded, with a dynDNS service and/or services from EndJunk can completely stop further incoming spam e-mails even after the disposable accounts have been re-enabled a few days later on. In the case of my experiment using my own MTA server, I did notice the mail kept bouncing back-and-forth as you explained above. However, that bouncing back-and-forth only lasted a few days and diminished. What I didn't do was to use a wireshark software to really look into the traffic to see if those bouncing back-and-forth did include e-mail body messages or only a handshake between to MTA servers. If it is the later one, then Internet bandwidth resources lost is at a minimal.

At any rate, SpamGourmet services seem to deliver its promise. I just wish SpamGourmet will add an option to bounce incoming spam e-mails so that those who run their own SpamGourmet system can take advantages of it.
habibie
 
Posts: 16
Joined: Sat Dec 10, 2011 1:27 am

Postby josh » Thu Jan 19, 2012 6:24 pm

habibie wrote:At any rate, SpamGourmet services seem to deliver its promise. I just wish SpamGourmet will add an option to bounce incoming spam e-mails so that those who run their own SpamGourmet system can take advantages of it.
It's open source :)
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby pblinks » Sat Jun 16, 2012 11:30 pm

josh wrote:
habibie wrote:At any rate, SpamGourmet services seem to deliver its promise. I just wish SpamGourmet will add an option to bounce incoming spam e-mails so that those who run their own SpamGourmet system can take advantages of it.
It's open source :)


I'm adding this to my sigfile :D
pblinks
 
Posts: 25
Joined: Sun Apr 18, 2010 1:15 am


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 22 guests

cron