Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> wrote:
- 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?
Hmm... you said that MTA's which received a 4yz from an MX would try
another MX. The RFC's say they should try another MX of the same
priority, before going to a lower priority.
Is it really that hard to figure out?
Do you mean send an TCP RST? I would not have guessed you would
propose a protocol with such a feature.
No, I'm proposing an approach to a solution. I've purposefully left
specific implementation details vague, as I believe there may be
different methods of achieving the same goals.
Another problem with your idea is that as far as I can tell, you are
making the false assumption that spammers retry.
I'm pretty sure you're not reading the messages I post. I NEVER
said spammers "retry". I said they "try" to deliver mail.
To use simple words: Unknown people sending a small number of
messages are punished a small amount under the system I propose.
Unknown people sending a large amount (i.e. spammers) are punished a
lot.
We can make a great leap of imagination, and realize that a site
implementing such a system would realize when "nice" people send it
lots of mail, and takes steps to lower their delivery costs.
(whitelists, etc)
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?
You're stuck on verbiage from the RFC's, to the point where any
proposed approach which *doesn't* use SMTP verbiage is rejected out of
hand by you. (That's not entirely true, you reject pretty much every
proposal, so far as I've been able to tell.)
A quick skimming of those two RFCs are sufficent to pick
up any and all useful jargon.
Ah... Please read "Fashionable Nonsense", by Andrew Sokal.
A simple description of whatever you
mean that is complete enough for any compenent programmer familiar
with SMTP to implement would be sufficient.
Exactly. If I describe a general approach to problem solving, you
get confused because I'm not using SMTP vocabulary. My apologies,
I'll try to use more obtuse vocabulary in the future.
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.
So my quote from RFC 974 is what, wrong?
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.
That's your loss, and your lack of imagination.
Data collection and filtering are general concepts, which apply both
to particle accelerators, and to spam. The methods used by others to
filter data SHOULD be used as a starting point in the search for data
filtering methods for spam.
Why reinvent the wheel?
Is the SPAM problem so magical that we can't learn anything from
other data analysis methods?
People who lack field-specific vocabularly tend to also lack field-specific
knowledge.
That's fine, but it shouldn't interfere with the "field experts"
ability to understand general concepts.
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.
I guess I won't rely on RFC 974 any more.
"Implementors are encouraged to write mailers so that they try the
MXs in order until one of the MXs accepts the message, or all the MXs
have been tried."
RFC 2821, Section 5 says:
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds.
But why should I believe the RFC's, if you disagree with them?
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg