At 10.42 -0700 01-01-19, ned(_dot_)freed(_at_)innosoft(_dot_)com wrote:
> But this is beside the point. You claimed to have a better alternative and
> I asked what it was. You haven't answered my question.
If the goal is limited to stop spammers from using other MTAs
to multiply their messages, it would be enough to stop multiplication
of external mail with more than, say 20 RCTP TO:s,
Been there, done that, doesn't work. Often as not spam isn't sent this way.
possibly also
noting if the same message is sent several times in 20-at-a-time
chunks.
The overhead of keeping these sorts of records is very high. And even if you're
willing to accept the overhead, it doesn't work when the messages are
customized.
If the goal is to really effectively stop spamming in e-mail,
this problem is very difficult. The cause of the difficulty
is that whatever action taken to stop spammers, the spammers
will find ways to circumwent it.
IETF had a BOF discussing spam some years ago, but as I
remember all or most of what was said would not work simply
because spammers can find other ways around them.
The BOF led to the publication of RFC 2635.
For example, relaying of foreign mail was not effective
in stopping spam (even if it was effective in stopping certain
kids of overloads of MTAs caused by spammers), because spammers
found other ways.
Again, stopping spam was never the primary goal of relay blocking.
Similarly, identification of many identical messages will
probably not work, because spammers have started to personify
their spams, including "Hello Jacob" in the text of spams
sent to me. This will make it difficult to identify duplicate
copies of spams.
Exactly. And you have now refuted your own assertion that relay blocking
isn't necessary.
What might possibly work would be something similar to
PICS servers - a database identifying spams. Like with PICS,
there could be different scales, so that different people
could have different opinions on what they want and do not
want. However, because mail is so rapid, such a data base
must be very rapidly updated, by many people (i.e. all
ISOC members except those who misuse the data base) allowed
to update the data base. And it must be able to stop messages,
which have already arrived at your mailbox, maybe even have
already been downloaded to your personal computer.
It's been tried. But the products I've seen that implemented this weren't
successful and are no longer available. Maybe there are some others
out there and maybe they will fare better, but I'm not optimistic.
Ned