Hi folks, I have an actual, no-bullshit operational opinion question relating to spamming and spamblocking :-) I'm working on the "intelligent bounce" software here for our spamblocker. Right now we don't support bounces for spamblocked messages, for the reason that the headers are often forged and thus the cycles to do this are wasted (or annoying the wrong person). Also, queueing the bounce back through Sendmail is usually a *bad* thing to do, because sendmail is way to aggressive in trying to deliver mail when you really want to make one pass at it and then give up. So I'm having the spamblocker dump the spam into a different place, where I then pick it up and post-process it to try to send the bounces back. The problem is the algorythm. My options appear to be: 1) Go to the "From" line WITHOUT MX resolution, and deliver there. If it fails, go to the relay which connected to us and send to {postmaster|abuse}. Advantages: We try to hit the exact machine the mail claims to be from. There's a good chance that if it DOES have an SMTP listener on it we'll get back a good reply to the RCPT TO command (either positive or negative). Disadvantages: Many sites don't run SMTP listeners on their machines which resolve to the domain name in the headers, and some don't even HAVE such a machine mapped with an "A" record to send to. This will send to abuse and postmaster where a real person might be reachable otherwise. 2) Go to the From line WITH MX resolution. I've already figured out that hitting secondary MXs is a bad idea, for the simple reason that most of them will say "220" to anything in the domain they're secondarying for, and what you REALLY want is to get back 400 or 500 errors if the username is forged (as it frequently is) so you can then hit the relay abuse address INSTEAD. Advantages: This follows most closely the real Internet standards practice. Its still not 100% complient, but again, we don't care if we're "wrong" in the area of failing to deliver one of these bounces. Disadvantages: The lookup time is non-trivial, and if the FROM line is forged you're going to harass the wrong person with the bounce. The second problem is particularly severe, since a "bad guy" can now pick on someone like "President@whitehouse.gov" and you're going to send the bounces to Mr. Clinton. Once its figured out what you're doing, now these spammers have a nice denial-of-service attack they can launch. This is already being done to some extent, and I'm not sure that its a good idea to give them more fuel. 3) Screw the From line and hit the relay site directly; try to deliver to the user there, and if it fails then hit abuse and postmaster instead. Don't bother trying to look up the From line on the premise that its forged anyway. Advantages: The relay site either has an SMTP server on it or it does not. If it does, then you just got to someone who SHOULD be able to put a stop to it. If it does not, then you're wasting your time ANYWAY, but you probably know about it almost immediately when it comes back with an RST to your SYN. If its some jerk on a dialup dynamic address account you'll probably time out (unless someone else is on the IP number now, in which case you get an RST) but again, its reasonably fast. Disadvantages: The user who sent the spam will frequently not get notified. If your spamfilter blocks a legitimate user, you may never get notification to that person using this method. In any case, if I fail to deliver the bounce on the first attempt I'm going to ditch it and NOT retry. Its not a big deal from my point of view if you don't get back every one of the 452,223 spams you send me - - if I return 450,000 of them that's enough :-) The intent here is to do the following: 1) Alert the real sender if we can reasonably reach the person. 2) Alert the relay owner if they were relayed through without knowing about it (and pressure them to fix it - pronto!) 3) If we can't do either right away, toss the bounce on the floor on the premise that its better to give up than keep screwing around and clog up the pipeline. What do the rest of you here think? Option (1) doesn't look very sound; the fight right now is between (2) and (3). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
The intent here is to do the following:
1) Alert the real sender if we can reasonably reach the person. 2) Alert the relay owner if they were relayed through without knowing about it (and pressure them to fix it - pronto!) 3) If we can't do either right away, toss the bounce on the floor on the premise that its better to give up than keep screwing around and clog up the pipeline.
What do the rest of you here think? Option (1) doesn't look very sound; the fight right now is between (2) and (3).
In my opinion, if you fix the relay problem to about 75%, the rest of the relays will get fixed or die, due to the spam volume, then one you solve the relaying problem, someone has to transmit all the messages themselves, which greatly lengths the time to detect them, and makes the cost of spamming go up. (It also allows IP based blocking to work better.) --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net
On Wed, Nov 19, 1997 at 12:48:27PM -0600, Jeremy Porter wrote:
The intent here is to do the following:
1) Alert the real sender if we can reasonably reach the person. 2) Alert the relay owner if they were relayed through without knowing about it (and pressure them to fix it - pronto!) 3) If we can't do either right away, toss the bounce on the floor on the premise that its better to give up than keep screwing around and clog up the pipeline.
What do the rest of you here think? Option (1) doesn't look very sound; the fight right now is between (2) and (3).
In my opinion, if you fix the relay problem to about 75%, the rest of the relays will get fixed or die, due to the spam volume, then one you solve the relaying problem, someone has to transmit all the messages themselves, which greatly lengths the time to detect them, and makes the cost of spamming go up. (It also allows IP based blocking to work better.)
Hmmm.. this seems to argue for the last approach - try to send the bounce to the FROM line at the relay, and failing that, send the bounce instead to {abuse|postmaster}@relay.site. The only reason I don't want to bypass the user ENTIRELY is that if the spamfilter gets someone who is legitimate (due to their being in the wrong place, etc) I want there to be a reasonable chance that they'll get notified by us that their mail was blocked and they need to talk to someone about it (they may be legitimately trying to reach a customer of ours). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
participants (2)
-
Jeremy Porter -
Karl Denninger