Subject: Re: [Asrg] Spam Control Complexity -- scaling, adoption, diversit y and scenarios

From: Vernon Schryver <[email-masked]>
Date: Sun, 20 Apr 2003 19:49:23 -0600 (MDT)

> From: Dave Crocker <[email-masked]>

> ...
> HBP> Content filtering requires only single ended adoption.
>
> And it is not subject to network standardization.  ...

I suspect that is more true than false, but more than half of the spam
control systems now in at least real trial use (stopping millions of
spam/day) involve aspects that could be subject to network standardization.
All of the following filter at only one end, but push lots of bits
through the Internet in support of that filtering:
  - Postini
  - Brightmail
  - MAPS's RBL using BGP feed
  - DNS blacklists including MAPS's RBL+, SBL, and SPEWS
  - Razor/Pyzor
  - DCC
(in no particular order.  no endorsements implied.  omissions unintentional)

SpamAssassin can also be viewed as moving data around the net in support
of its content filtering in the form of updates to the default scoring.

Of all of those, only SpamAssassin sounds like a good candidate for
network standardization, but I think it is a candidate.  The others
have protocols that would be hard to displace.

The only spam solutions that I can think of that might be called
"double ended" are
   - authentication
   - sender-pays (money, CPU cycles, or anything else)
   - challenge/response

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2003 23:09:43 -0700

Vernon,

>> And it is not subject to network standardization.  ...

VS> I suspect that is more true than false, but more than half of the spam
VS> control systems now in at least real trial use (stopping millions of
VS> spam/day) involve aspects that could be subject to network standardization.

I like filtering systems.  I think it likely that multiple such
mechanisms will be a permanent part of the email landscape forever.

None of that is relevant.

This is an IRTF group.  It is presumably, therefore, intended to focus
on activities that are likely to be reasonable candidates for format
and/or protocol standardization.

So the problem with your saying that an activity "could be subject to
network standardization" is that you give no indication to what. While
I could try to guess, it would be far more helpful to hear how "single
ended" mechanisms, like receiver filters, offer an opportunity for an
interoperability (ie, networking) standard.

VS> SpamAssassin can also be viewed as moving data around the net in support
VS> of its content filtering in the form of updates to the default scoring.

That fact that some software has contact with a network does mean that
it is a candidate for a networking standard.  So please indicate what
mechanisms and/or formats you have in mind.

VS> The only spam solutions that I can think of that might be called
VS> "double ended" are
VS>    - authentication
VS>    - sender-pays (money, CPU cycles, or anything else)
VS>    - challenge/response

Any spam-related mechanism that involves some sort of accounting or
management among independent, cooperating components offers reasonable
possibilities, too.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 21 Apr 2003 09:06:43 -0600 (MDT)

> VS> spam/day) involve aspects that could be subject to network standardization

> interoperability (ie, networking) standard.

For the entries on my list:
  - Postini
      detours mail through special MTAs that filter.  The link between
      the specialized filter MTA and the Postini customer's real MTA
      is (or ouught to be--I don't really know) already standardized
      as SMTP-AUTH or SMTP-TLS.

  - Brightmail
      communicates samples of spam from spam traps to Brightmail's
      control center (centers?) and filter parameters, expressions,
      checksums, or whatever back to customers.  The protocol that
      carries the filter parameters sounds like a good IETF/IRTF
      standardization candidate, except that Brightmail is proprietary.
      (I know little about Brightmail, so this is a guess.)

  - MAPS's RBL using BGP feed
      used BGP which has already been and continues to be subject to 
      network standardization.

  - DNS blacklists including MAPS's RBL+, SBL, and SPEWS
      used DNS which has already been and continues to be subject to 
      network standardization.  DNSSEC sounds like a good idea here.

      It might be good if the IETF/IRTF would standardize the values
      returned by DNS blacklists.  There is currently an ad hoc and
      inconsistent protocol using IP addresses in 127/8 to mean "this
      sender is a bad spammer," "this sender might be bad," "this sender
      was bad," and other things.

      Then there is the possiblity of a protocol that fits the question
      "should I accept a message from this IP address or sender" better
      than DNS PTR RRs.

  - Razor/Pyzor
      communicates checksums of spam with what I think was originally
      a purely ASCII protocol but is now somehow related to base64.

  - DCC
      communicates a total of several GBytes/day of checksums of spam
      and target counts between thousands of mail filtering clients
      and checksums clearinghouses with a UDP based protocol and among
      clearinghouses all over the world over TCP.  The binary UDP
      based protocol can be viewed as a specialized RPC protocol and
      has the usual authentication, retransmission, real time, and
      other aspects of remote procedures.  The TCP based protocol is
      intended to communicate checksums of bulk mail to all of the
      current more than 120 clearinghouses in the network within
      seconds of discovery.  It has typical authentication and other
      needs.  Both of those protocols could be subjects of the IRTF/IETF
      if they did not already exist and if the guy responsible were
      not so hopelessly not a team player.

> mechanisms and/or formats you have in mind.

SpamAsassin assigns "scores" to dozens of features of a message.  If
the score is high enough, the message is either rejected or set asside.
As common features in spam change, the set of scores that are most likely
to indicate evil change.  SpamAssassin also uses regular expressions.
A naive and bad protocol would be to distribute control files or patches
to control files from spamassassin.org or an origanization's control
center.  See http://www.spamassassin.org/doc/Mail_SpamAssassin_Conf.html
A better protocol might encode snippets of filter-expressions, default
scores, the identity of its source, and an authenticator, all more densely
than ASCII.

> management among independent, cooperating components offers reasonable

Yes.

I guess that I disagree with your statement that mere contact with the
network is not sufficent to justify IETF/IRTF consideration.  Spam 
always involves at least SMTP.  There have been several proposals to 
  - modify SMTP delivery status notifications to avoid flooding innocent
     mailboxes as a result of forged senders
  - codify best current practices of filters to minimize sending DSNs
  - improve DSNs so that people or computers could recognize spam filtering
  - replace SMTP with something or other.
All of those could be considered or explicitly and officially rejected
by the IETF/IRTF.

There is plenty that the IETF/IRTF might do about spam.  Based on the last
six weeks here and years of efforts elsewhere, I think the hard part isn't
the doing but ignoring noisy committee go-ers and other disruptions.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 21 Apr 2003 09:18:22 -0600 (MDT)

As I plod through the dozens of messages that appeared in my mailbox
in the last few hours, I'm reminded of another thing that the
IETF/IRTF might do for "single ended filters." Some of those messages
are double bounces from a system that is an MX secondary.  The
bounces are for spam that was accepted by the secondary, refused
by the primary, and cannot be returned to the spammer.  Even the
most non-network oriented single-ended filter would benefit from
protocols that coordinate MX secondaries.

Many spammers prefer to send to MX secondaries because secondaries
are often not as well filtered as MX primaries.  As a result of
the lack of MX secondary coordination protocols, the best advice
for all but large sites is to stop using MX secondaries.

There are other opportunites for IRTF/IETF work.  A protocol missing
from the DCC and other anti-spam systems that use whitelists and have
logs is a way to communcate white-lists logs of rejected mail among
MX secondaries.  I keep suggesting rdist/ssh and NFS to operators of
MTAs using the DCC, and but very, very few like those ideas.

---

From: Andrzej Filip <[email-masked]>
Date: Mon, 21 Apr 2003 19:30:21 +0200

>for all but large sites is to stop using MX secondaries.
You can make secondary mail server know valid addresses in the domain 
and reject the remaining.
Such solutions for sendmail have been discussed a few times in 
news:comp.mail.sendmail :
a) virtusertable for non local email domains
b) LDAP based routing [FEATURE(`ldap_routing')]
If you need more details ask on news:comp.mail.sendmail

I suggest to change wording of the recommendation because I also think 
that secondary that accept message to invalid address in the domain is 
not a good idea.

-- 
Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 21 Apr 2003 15:07:13 -0400

> and reject the remaining.

  Even better.  Have 3-4 "secondaries" hosted at the same site, and
have others off-site.

  It's fairly straightforward to classify mail into different "bins",
by abusing the interpretation of MX priority records.  This proposal
requires some additional local administration over current methods,
but I'll propose it here as a "straw man".

  The idea is to locally interpret (or abuse) MX priority records.
The following table illustrates the network setup:

  Priority    MTA Activities
  --------    --------------
  1	      source IP filtering, accepting email only
	      from a set of whitelisted IP's.

  2	      what (1) does, plus ident/RMX

  3	      (2), plus spam filtering

  .	      ... even more graduated filtering

  The idea is that the other end *already* walks down the list of MX's
by priority, if there's a delivery error.  We can abuse this behaviour
to allow the people we know (whitelisted) to connect with no cost.

  People we don't know suffer a small penalty for delivering mail at
the STMP level (users shouldn't see this), and will fall back to using
a lower-priority MX.  The more spammers try MX 1, the more they get
punished, as their connections are rejected or silently dropped.

  This method also allows the incoming email to be trivially
classified with little local work.  "Gold" email comes from IP's on a
whitelist, and any anti-spam content filtering can err on the side of
caution.  "Silver" email comes from people who are traceable, and who
have publicly declared their identity.  "Bronze" email comes from
everyone else.

  No email is dropped from anyone, unless the "bronze" content filters
decide to do that.  No one outside of the mail system even knows that
this is happening.

  I haven't spent a lot of time thinking about this, but the general
approach is similar to that used by Physicists in particle
accelerators.  They have terabit streams of data, which are passed
through successive "sieves", to filter and classify the information
into multiple pre-digested sub-streams.

  Comments?

  Alan DeKok.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 21 Apr 2003 14:29:04 -0600 (MDT)

> You can make secondary mail server know valid addresses in the domain 

In the real world, that is wrong.  Only when the MX secondaries are
either unneeded or practically the same computer as the MX primary
can you hope to have a common list of valid addresses.  The rest of
the time, there are compelling practical and policy reasons that keep
MX secondaries from having a common and complete list of valid addresses.
Moreover, this is entirely irrelevant to problem mentioned.

> a) virtusertable for non local email domains

That is irrelevant to the problem I'm talking about as well as not
useful for the problem you are talking about.

> b) LDAP based routing [FEATURE(`ldap_routing')]

Thaty is irrelevant to the problem I'm talking about as well as
a doubtful solution for the problem you are talking about.

> If you need more details ask on news:comp.mail.sendmail

A newsgroup is rarely my first suggestion for technical information,
particularly in a forum where contributors should be expected to know
far more about the topic than the vast majority of contributors to
newsgroups.  Far better sources for information about sendmail include
the sendmail "ops" document, the cf/README file, the sendmail source,
and the many web pages at http://www.sendmail.org.

> that secondary that accept message to invalid address in the domain is 

Please re-read what I wrote and consider the context.  The reason the
primary MX server rejects the messages that have come through the
secondary MX server is that they fail either DCC or sendmail access_DB
filtering.  The target addresses are entirely valid.  The invalid
addresses are the nominal senders of the spam.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 21 Apr 2003 14:39:15 -0600 (MDT)

> From: "Alan DeKok" <[email-masked]>

> by priority, if there's a delivery error. 

What standards compliant SMTP client does that?  
Instead an SMTP client only walks down the list of MXs when the MXs
are completely silent to the TCP SYN to port 25 or respond with
an ICMP Unreachable. 

Once a client gets a SYN-ACK, it is supposed to continue to the end
of the SMTP transaction and either forget the mail message entirely
if it gets a 2yz to the DATA command or 5yz response to any command,
or try again later starting with the lowest numbered MX server if it
gets a 4yz response to any command.

Section 3.9 of RFC 2821 says that other cases such as broken TCP
connections "SHOULD ... treat the mail transaction as if a 451 response
had been received."

>                                            We can abuse this behaviour

Not unless they use broken MTAs.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 21 Apr 2003 17:09:04 -0400

> What standards compliant SMTP client does that?  

  <shrug>  So list them all as equal priority.  RFC 974 says:

  "All MXs at with a given value must be tried before any of a higher
   value are tried"

  Minor details in the implementation of the idea don't prevent it
from working.

  Alan DeKok.

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 21 Apr 2003 17:26:36 -0400

>       "should I accept a message from this IP address or sender" better

In particular, indicating whether it should be bounced or deferred 
would be useful for different classes of "bad" IPs.  (more on this 
later)
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 21 Apr 2003 17:52:25 -0600 (MDT)

>   "All MXs at with a given value must be tried before any of a higher

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. 

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.  RFC 2821 seems to be intentionally vague about how
long an SMTP client should wait before retrying, but typical sendmail
"queue runs" are separated by 5 to 30 minutes.

>   Minor details in the implementation of the idea don't prevent it

well....

---

From: [email-masked]
Date: Mon, 21 Apr 2003 20:18:57 -0400

On Mon, Apr 21, 2003 at 09:06:43AM -0600, Vernon Schryver wrote

>       was bad," and other things.

  Off the top of my head, I don't think that's possible.  About the only
standardization I've seen so far is that *SINGLE-CHOICE* (binary yes/no)
lists generally return 127.0.0.2, and all that means is that the queried
IP address is on the list... of what?  Dynamic IP addresses, open
relays, proxies, known spamhausen, whatever.  In order to cut down on
DNS queries, there are some "aggregator" DNSbls that allow you to
effectively ask multiple questions with one query.  relays.osirusoft.com
has multiple possible return codes.

http://relays.osirusoft.com/faq.html#_Toc533558164

* 127.0.0.2 Verified Open Relay
* 127.0.0.3 Dialup Spam Source
  Dialup Spam Sources are imported into the Zone file from other sources
  and some known sources are manually added to the local include file.
* 127.0.0.4 Confirmed Spam Source
  A site has been identified as a constant source of spam, and is
  manually added. Submissions for this type of spam require multiple
  nominations from multiple sites. Test Blockers also find themselves
  in this catagory.
* 127.0.0.5 Smart Host (In progress)
  A Smart host is a site determined to be secure, but relays for those
  who are not, defeating one level of security. When this is ready, it
  will be labeled outputs.osirusoft.com. NOTE: I strongly discourage
  using outputs due to it being way too effective to be useful.
* 127.0.0.6 A Spamware software developer or spamvertized site. This
  information is maintained by spamsites.org and spamhaus.org.
* 127.0.0.7 A list server that automatically opts users in without confirmation
* 127.0.0.8 An insecure formmail.cgi script. (Planned)
* 127.0.0.9 Open proxy servers

  Similarly, some people block certain countries.  Rather than querying
cn.countries.nerd.dk, kr.countries.nerd.dk, tw.countries.nerd.dk, etc,
you can query an IP address in the zz.countries.nerd.dk "superzone".  It
returns 127.0.X.Y where (X * 256) + Y = the ISO numeric country code of
the country of origin of the IP address.

  Rather than re-working that which already works, how about looking to
the future, where standards designed today can actually be implemented
from square one?  IPv6 uses ::1 as the loopback address, rather than a
whole 2 ^ 24 addresses.  Under IPv6, do DNSbls continue to return
addresses in the ::127.0.0.0/104 CIDR?  Is there a *GUARANTEED*
will-never-be-used range elsewhere that might be better suited?  In
which case, how do DNSbls handle the transition period?

>       "should I accept a message from this IP address or sender" better

  Given that the current DNSbl "protocol" (ad-hoc as it may be) works, I
think the proper question is what's-broken/needs-fixing/can-be-improved.
And the changes, if any, should be implemented in IPv6 only so they don't
have to be re-done a few years from now.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 21 Apr 2003 21:45:46 -0400

> first or any MX server that answered at all. 

  Note that I didn't say *any* MTA would response with a 5yz error
message.

> 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.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 21 Apr 2003 21:09:48 -0600 (MDT)

> - 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.

> - 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.

> signficant overlap between what I proposed, and your understanding of

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.

> 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.

> 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

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.

---

From: Andrzej Filip <[email-masked]>
Date: Tue, 22 Apr 2003 07:58:32 +0200

>MX secondaries from having a common and complete list of valid addresses.
*Good* policies are not the same everywhere. I have seen a few 
implementation of "shared" domain with every of the servers capable to 
act as primary or secondary MX for the domain.
BTW there is no need to keep "complete list of valid addresses" - MD5 
checksums would be sufficient and easy enough to implement.

>Moreover, this is entirely irrelevant to problem mentioned.
It was about primary bouncing messages accepted by secondary. If 
secondary accepts messages to non existing addresses  then bounces 
handling create problems approaching DoS when receiving mass "dictionary 
recipients" spam. Before "dictionary recipients" spam it had not been 
that critical.

So, it is not *entirely* irrelevant but I adresses different cause of 
"spam bounces" that you wrote about.

>>[...]

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 22 Apr 2003 10:06:31 -0400

> 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?

> 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.

> 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)

> 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

  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.

> 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?

> 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?

> 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 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.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 22 Apr 2003 09:24:13 -0600 (MDT)

>   But why should I believe the RFC's, if you disagree with them?

In practice, those words are understood as applying only to a single "queue
run" or attempt to send a message.  An SMTP client tries the MX servers
for a domain name until it finds one that answers the TCP SYN.  It then
tries to delivere the message.  If it receives a 5yz result, it forgets
entirely about the message (except for the exception that is treated like
a 4yz result).  If it receives a 4yz result, it saves the message but
forgets all of the details of its efforts until the next "queue run."
Your notion is based on one or or both the obviously bad ideas:

  1. STMP clients treat a 4yz as needing an immediate retry at another
     SMTP server.  This is obviously bad because 4yz responses mean
     "try again *LATER*."  MX RRs often point to the same host (e.g.
     when it is multi-homed) and even if not, trying again immediately
     at an SMTP server related to one that has said "I'm too busy try
     again later" violates the spirit of "try again later."

  2. SMTP clients remember which the MX servers they have tried in
     previous "queue runs".  This is obviously a bad idea because
     it would make it make it hard to change DNS data if SMTP clients
     cached it indefinitely.  No, SMTP clients could not look at old
     and new DNS data and merge changes.  Moreover, after the RFC 2821
     suggested 30 minute delay (see section 4.5.4.1) it would be
     silly to restart with a secondary or tertiary MX server.

Please do not send me any more mail.  We lack sufficient mutual regard.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 22 Apr 2003 11:48:48 -0400

Vernon Schryver <[email-masked]> wrote:
>      SMTP server.

  That wasn't my intention, and I tried to make that clear.

>      previous "queue runs".

  I didn't say that.  That appears to be your understanding of how you
would implement my proposal.

> Please do not send me any more mail.  We lack sufficient mutual regard.

  <shrug> I admit I'm imperfect.  I realize I don't know as much about
details of SMTP as many others on this list, yourself included.

  I had hoped people would offer criticisms, suggestions, or comments
to my "straw-man" proposal.  It wasn't meant to be perfect or
implementable as-is. It was intended only to stimulate discussion.

  I'm disappointed that the only discussion involved reading things
into it which weren't stated, or intended by me.

  Alan DeKok.

---

From: Claus Assmann <[email-masked]>
Date: Tue, 22 Apr 2003 09:10:24 -0700

> run" or attempt to send a message.  An SMTP client tries the MX servers

By whom?

>      again later" violates the spirit of "try again later."

8.12.0/8.12.0   2001/09/08
...
        If sendmail receives a temporary error on a RCPT TO: command, it will
                try other MX hosts if available.

You may want to check other MTAs. AFAIK only qmail behaves the way
you describe. The RFC is unfortunately not clear in this point.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg