North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Problems sending mail to yahoo?

  • From: Barry Shein
  • Date: Sun Apr 13 20:14:09 2008


Massive quoting gets old fast so I'll try to summarize and if I
misrepresent your POV in any way my profuse apologies in advance.

First and foremost let me say that if we had a vote here tomorrow on
the spam problem I suspect you'd win but that's because most people,
even (especially) people who believe themselves to be technically
knowledgeable, hold a lot of misconceptions about spam. So much for
democracy.

I say the core problem in spam are the botnets capable of delivering
on the order of 100 billion msgs/day.

You say there are other kinds of spammers.

I'll agree but if we got rid of or incapacitated the massive botnets
that would be a trickle, manageable, and hardly be worth fussing
about, particularly on an operational list.

The reason is that without the botnets the spammers don't have address
mobility. You could just block their servers.

But if we don't agree on those points then we're talking past each
other.

I assert that the problem are the massive O(100B) botnet spammers and
they simply don't have the resources or interest really (because they
don't have the resources or business model) to do things like analyze
return codes etc as you describe.

So it's doubtful to me that returning more meaningful return codes in
SMTP rejections would be of much use to them.

It's also not of much use to them, as I previously described, even if
they tried. They could deduce about the same information for about the
same "price" without the return codes.

But any such return codes should be voluntary, particularly the
details, and a receiving MTA should be free to respond with as much or
as little information as they are comfortable with right down to the
big red button, "421 it just ain't happenin' bub!"

But it was just an example of how perhaps some standards, particularly
regarding mail rejection, might help operationally. I'm not pushing
the particular example I gave of extending status codes.

Also, again I can't claim to know what you're working on, but there
are quite a few "disposable" address systems in production which use
various variations such as one per sender, one per message, change it
only when you want to, etc. But maybe you have something better, I
encourage you to pursue your vision.

And, finally, one quote:

>I didn't say I had a design.  Certainly there are solutions to the
>problem, but any solution I'm aware of involves paradigm changes of
>some sort, changes that apparently few are willing to make.

Gosh if you know of any FUSSP* whose only problem is that it requires
everyone on the internet to abandon SMTP entirely or similar by all
means share it.

Unfortunately this is a common hand-wave, "oh we could get rid of spam
overnight but it would require changes to (SMTP, usually) which would
take a decade or more to implement, if at all!"

Well, since it's already BEEN a decade or more that we've all been
fussing about spam in a big way maybe we should have listened to
people with a secret plan to end the war back in 1998. So I'm here to
tell ya I'll listen to it now and I suspect so will a lot of others.

* FUSSP - Final and Ultimate Solution to the Spam Problem.

-- 
        -Barry Shein

The World              | bzs@xxxxxxxxxxxx           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*