At 10:53 PM -0700 5/17/04, Hallam-Baker, Phillip wrote:
Spamware could parallel connections to umpteen million recipients and
send at full speed if all it had to do was wait.
Absolutely, this code is not your standard mail client stuff.
That depends on what you mean by 'mail client.' There are common
modern MTA's that will parallelize quite heavily by default, and for
most of a decade there have been transport agents designed for
mailing lists with tunable parallelization.
The class of spammers that seems to have the biggest problem with
slow transaction times has a logically intrinsic problem there. These
are the compromised machine users, who are not free to tune systems
for broad parallelization and for whom longer per-host connect times
and/or broad parallelization per harnessed zombie mean greater
likelihood of getting caught and evicted from the machines they
trespass on sooner than if they simply fire off all of their outbound
data for a single target as if assuming that all responses will be
positive. There is at least one spammer/ratware combination in
operation right now that is actually sending the entire client-side
part of an SMTP session in a single TCP segment.
> Or for that matter just don't respond with a 250 to their HELO for N
> seconds and if they continue talking anyhow drop the connection
> (something like this is in the current beta sendmail, 8.13.0beta.)
That works currently against spamware that pipelines illegally. If it
becomes more common, that spamware will become less common.
Problem is that there are lots of people using these techniques for
good reason. 'illegal' is a poor choice of language, SMTP is not an
act of parliament, nor is it a particularly great design.
I'm not sure that you and Seth are understanding 'pipelines
illegally' in the same way. There is a defined standard for when and
how an SMTP client can pipeline which includes some carefully
reasoned times when pipelining cannot be correct behavior. Spamware
today breaks the natural rules about what can be pipelined, not just
the social rules about whether a sender should try pipelining when
the EHLO response isn't there.
If you
need to send out a million mails to your customers as Ebay does every
day you cannot wait around a minute while someone's idiot sendmail
script runs.
1. Yes, you can. It's a parallelization issue for the sender, and
legitimate high-volume senders deal with 30-90 second delays per SMTP
command all the time. It is an issue of system design and tuning.
2. Using Ebay as an example of a legitimate mailer is a cute bit of
humor. I understand that they are a very different operation from the
zombie herders, but it is of dubious value to look at the problem
of spam technically only and reference chronically unethical
high-volume mailers like Ebay, Verisign, Microsoft, Digital Impact,
Topica, and Yahoo as a set that needs to fit within any technical
approach. (and yes, that's a very incomplete list) It may be that in
order to address the behavior of the Alan Ralsky's and Scott
Richter's of the world, the big guys who are not doing anything that
is criminal (at least not in the US and/or not yet proven in a court
of law) and have names everyone knows will have to rework or even
abandon their use of email as a broadcast medium.
Spam is a problem in large part because of the non-uniform economies
of scale that have existed for email and the unreasonable
expectations of economies of scale extending into very large scales,
i.e. that because there is not a tenfold difference in capital and
operational cost between sending to one hundred and one thousand,
that there should not be a tenfold increase in cost between a hundred
thousand and a million. It is that sort of expectation which drives
the 'legit' companies to cut corners on ethical list management and
whine about being unable to handle delays (where 'handle' really
means 'comfortably fund the needed resources to work with') and leads
to the sort of behavior that the NYAG has documented: subcontracting
layers leading from seemingly legitimate companies down to zombie
rustlers.
--
Bill Cole
bill(_at_)scconsult(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg