From: "Alan DeKok" <aland(_at_)freeradius(_dot_)org>
...
Which is the behaviour I described as being useful:
- if one MX doesn't accept the message, another MX is tried
How does one MX not accept the message without saying 5yz or 4yz?
Do you mean send an TCP RST? I would not have guessed you would
propose a protocol with such a feature.
- 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
I think that would involve at least hours and potentially days of delays,
because a TCP RST would be treated like a 4yz, as RFC 2821 requires. Each
attempt would wait for the next queue run, which is typically 30 minutes.
(I've shipped major commercial versions of sendmail that used 15 minutes
as the default, but most people disagreed with my choice.) If the
arbitrarily chosen MX happens to always be the same one that drops the
TCP connection, the message would never get through.
Note that I wrote "arbitrarily" instead of "randomly chosen" because
"random" implies things that are wrong about SMTP and DNS.
- the more spammers try & get rejected, the more they're punished
Well, someone would be punished, but not necessarily spammers.
Another problem with your idea is that as far as I can tell, you are
making the false assumption that spammers retry. Of necessity, major
spammers send once, pay very little attention to status code, never
retry, and use extremely short timeouts when they don't use illegal
command pipelining and so send the entire SMTP transaction in a single
TCP segment, disconnecting before the target has seen even the HELO.
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.
Slathering I-D boilerplate on an idea does not make it more clear.
What do you mean by "vocabulary and references from the RFCs"? What
words are better for talking about SMTP than those in RFC 2821 and
RFC 2822? A quick skimming of those two RFCs are sufficent to pick
up any and all useful jargon. A simple description of whatever you
mean that is complete enough for any compenent programmer familiar
with SMTP to implement would be sufficient.
As far as I can tell, what you are proposing is based on the bogus
notion that SMTP clients step through MX servers until they find one
that will accept the message. My references to RFCs have been intended
to support my claim that SMTP client's simply don't and "MUST NOT" do that.
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.
Analogies are fine, but only as far as they go. I don't see any
significant analogy between the work at CERN or the computers and
networks used there and spam.
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.
Speak for yourself and your own spam solutions, or at least the
various toys and snakeoil. Spam solutions in real use tend to be
like SpamAssassin in offering local administrators too many choices
and too much control.
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.
People who lack field-specific vocabularly tend to also lack field-specific
knowledge. Frankly, I'm at a loss about what you're talking about.
I thought you knew more than enough about STMP to know that that
standards compliant SMTP clients don't keep trying MX servers until
they find one that will accept a message, but that seems to be the
crux of what you are assuming.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg