[rescue] Spam (was: Perverse Question)
Curtis H. Wilbar Jr.
rescue at hawkmountain.net
Sun Jun 8 09:26:01 CDT 2003
>Date: Sat, 7 Jun 2003 23:50:17 -0400
>From: Charles Shannon Hendrix <shannon at widomaker.com>
>To: The Rescue List <rescue at sunhelp.org>
>Subject: Re: [rescue] Spam (was: Perverse Question)
>X-Message-Flag: Microsoft Loves You!
>On Sat, Jun 07, 2003 at 04:13:24PM -0400, Rich Kulawiec wrote:
>> Ow. Owwww. OWOWOWOWOOWW. My head hurts already.
>I think it won't be that bad.
>For one thing... you start implementing it on the big servers first.
>What they do first is they annoy the other mail server admins
>and the users, and they bounce only a small portion of the email.
>Escalate until the pain forces upgrades.
>If you do this, I think fixes will be deployed rather quickly.
>Pain is a powerful motivator.
>I believe this is how the move to TCP/IP was handled. It was an
>escalation of pain and a hard deadline, right?
That was on a much smaller scale.... any technical protocol change
will have to be phased in.
>> This is already long, but let me touch on the RMX ("reverse MX") idea(s)
>This would probably help.
It is a simple idea that would help. It is one of the simpler solutions
I've heard (a coworker of mine had the same idea about 6 months ago).
>Combine it with a reverse MX for each hop in the headers and it should
>be nearly foolproof.
This would be augomagic once every mailserver was using this... each
hop would check the hop before it for a RMX.
Another idea I had works similarly to the way certificate authorities
work..... a legit mail server would be registered and and it's registration
could be checked against the authority. Just like getting a certificate
you have to prove identity, etc to get one. Only problem with this method
is increased costs. Who is going to manage the authority ? What are
the costs ? There would be more traffic than verifying secure web
certificates too... along with bandwidth... meaning hard costs to
whomever this authority would be.
Another idea on stopping proxies and direct connects with a mailserver is
to attempt to make an SMTP connection back.... if you can't it isn't a
mailserver. Of course this has an added problem in that many ISPs
(especially large ones) use outbound mailservers that either will not
answer or are filtered from taking smtp connections from the outside....
so the idea does have a big wrinkle.
>However, this is a big traffic increase.
One DNS lookup for each SMTP hop (usually 1-3 server to server hops)...
looked up off of caching DNS servers.... can't see this being a big
>> And it will be a huge argument and a nasty, painful process of
>> Which is why I still think it's simpler to just unplug the spammers.
>That's not a solution, though.
>I think tightening up SMTP transfer is the only way in the long run.
I hate to say it, but I think the solution will be a technical one....
but there is a snag.... if legislation serves to make spam legit to
any degree, they will not have a problem working within the new
system (although they will probably be much easier to filter at that
>UNIX/Perl/C/Pizza____________________s h a n n o n at wido !SPAM maker.com
>rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
I'm nog on the geeks list... but I think this should be in geeks, no ?
Hawk Mountain Networks
rescue at hawkmountain.net
My e-mail is protected against viruses and spam by MailGuardian
Top notch protection at unbelievable prices
More information about the rescue