Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> wrote:
You're missing the point. Any sort of filtering failure must be
treated as a permanent error by standards compliant SMTP clients. A
standards compliant SMTP client will never try another MX server of
any value for a given message after it has received a 5yz from the
first or any MX server that answered at all.
Note that I didn't say *any* MTA would response with a 5yz error
message.
A standards compliant SMTP server will not immediately retry with any
other MX server after a 4yz from any MX server, but will instead try
again with the same (see page 42 of RFC 2821) or some other lowest
value MX server.
Which is the behaviour I described as being useful:
- if one MX doesn't accept the message, another MX is tried
- messsages get distributed among MX's
- some minor time delay is OK
- the end user doesn't know the message is delayed
- messages eventually get through
- the more spammers try & get rejected, the more they're punished
Was it necessary for me to write an I-D, and spell out all of the
details, using specific vocabulary and references from the RFC's? I'm
wondering why your focus was on rejecting the idea, and why you missed
signficant overlap between what I proposed, and your understanding of
existing systems.
As a more general idea, it's one I haven't seen applied to spam
filtering before. The model used by particle accelerators has proven
to be successful for data rates that make spam look non-existent.
Data can be passed through overlapping sets of "filters", of gradually
increasing complexity, which allows the data to be grouped into
sub-types, with various levels of confidence.
Many anti-spam systems (and proponents) seem to be of the "all or
nothing" variety. The systems aren't designed to work together, which
gives local administrators little choice, and little control over the
problem. They also give little hope for solving the problem, but they
do give some people the intellectual satisfaction of putting down
anyone who talks about ideas without using field-specific vocabulary.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg