Subject: Message-ID, FQDN, and authority

From: Ofer Inbar <[email-masked]>
Date: Thu, 3 Jun 1999 16:57:37 -0400 (EDT)

The Message-ID RHS is a fully qualified domain name.  This is widely
deployed and widely understood to be "standard", and the only reason
it's not in RFC822 is because 822 is so very old.  We are charged with
updating 822 to match current usage, among other things.  This
particular aspect of current usage is entrenched enough that most
people familiar with mail protocols, upon seeing a Message-ID that
does not have a fully qualified RHS, immediately assume without much
further thought that the Message-ID in question is either bogus,
mangled, or was produced by broken software.

I initially thought a RECOMMENDED or SHOULD was enough for this.
However, Larry Osterman's posts have changed my mind.  Essentially,
his arguments boil down to:

1. We need a SHOULD so that our software doesn't get branded
   non-compliant when a host is improperly configured and doesn't know
   its domain name.
2. With a good enough algorithm for the LHS, what you put on the RHS
   isn't important.  You can be "unique enough"
3. With a bad algorithm of policy for the LHS, using fully qualified
   RHS won't save you from collisions.

Argument 3 is a given, but not particularly relevant to the issue.
Yes, the LHS algorithm-and-policy needs to ensure local uniqueness.
If it doesn't, the system doesn't work.  If it does, then the system
does work, assuming the RHS is fully qualified.

Argument 2 seems to be a proposal for some other system of doing
globally unique message IDs.  It may be a perfectly reasonable way to
do things, but it's also not relevant.  WE ALREADY HAVE A SYSTEM that
is perfectly reasonable.  Larry, I repeat, WE ALREADY HAVE A SYSTEM.
Whether or not some other way of doing it could also work is only
relevant if the way we're doing it now can't work.  In other words,
it's not relevant.

Argument 1 is the one that matters.  Seeing someone in Larry
Osterman's position make that argument, convinces me that SHOULD is
simply not strong enough.  Therefore, I change my mind.  A fully
qualified RHS for Message-ID is a MUST.

----------------------------------------------------------------------

Some of the comments I've seen here seem to indicate a lack of
understanding of what a fully qualified domain name is, what the DNS
is, and most importantly, *why* using fully qualified names is a good
idea and what we get out of doing it.  So, I'm going to err on the
side of explaining too much, here.  Pardon me if it really is too
much, as it undoubtedly will be for most readers.  My intent is not to
be condescending, but to make sure I cover it all without making too
many assumptions about what "everyone" knows.

What does "fully qualified domain name" mean?

It does NOT mean that the RHS must be the FQDN of the host on which it
is generated.  It does NOT mean that the RHS must be a resolveable
hostname, corresponding to any particular type of DNS RR (such as an
A, or MX, or whatever).

"Fully Qualified", in DNSese, means simple that it STARTS AT THE ROOT.

That's all.

What does this buy us?

The DNS root zone is an Internet-wide standard method of delegating
authority over a well-defined space of names, whose grammar also
happens to match the grammar RFC822 gives for the RHS of a Message
ID.  Anyone and everyone may register sub-spaces of this global
namespace, and be given full authority to manage their sub-spaces and
even to further delegate parts of them.  It is a very flexible system
that nevertheless gives an unambiguous method of determining who has
authority over a particular name.

Athority, in the DNS, is defined by "zones", and the boundaries
between zones are marked by SOA ("start of authority").  Any name that
matches DNS grammar can also be matched to a DNS zone, once you assert
that name is fully qualified.

For example, "TONTO".  Who has authority for that name?  Well, if you
assert that it is fully qualified, it's pretty clear.  Starting at the
root SOA, you try to walk down the tree.  You find no SOA delegation
for "TONTO".  Therefore, the root zone has authority for that name.
If you speak in the name of the DNS root, you are authorized to
generate Message-IDs with a RHS of "TONTO".

If, on the other hand, there is no assertion that this name is fully
qualified, it is impossible to determine who has authority over it.
Someone may develop a global email system of some sort, based on
RFC822, call it Tonto, write an RFC for it, and be granted the TLD.
And someone else may have a host named TONTO and decide that means
they can general @TONTO Message-IDs because it's their hostname.  Yet
another party may write the email software for the City Hall of a city
named Tonto, and decide that they, too, can generate @TONTO IDs.

That is why we need to assert that whatever appears on the RHS of a
Message-ID is in fact a fully qualified domain name.  Then, looking at
that name, simply walk down the DNS tree to the "most specific" SOA
that is visible to you, and you have identified the party responsible
for the generation of that Message-ID.  That party is the one that
takes responsibility for the algorithm & policy used to generate the
LHS, and to ensure that LHS is different from any other LHS generated
for that same RHS.

----------------------------------------------------------------------

We can suggest, perhaps even with a SHOULD, that the RHS used be the
fully qualified Internet domain name of the host system that generates
the Message-ID.  And we can all certainly see valid reasons for not
following that specific rule, which is why it can't be a MUST.  But we
can force, with a MUST, the interpretation of any RHS as a fully
qualified domain name, no matter what algorithm or policy is used to
generate it.

Not only because it makes sense, but also because it is effectively
ALREADY THE STANDARD.

  --  Cos (Ofer Inbar)  --  [email-masked]  [email-masked]
 "OSI is a beautiful dream, and TCP/IP is living it!"
   -- Einar Stefferud <[email-masked]>, IETF mailing list, 12 May 1992

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jun 1999 14:56:17 -0700

>qualified domain name, no matter what algorithm or policy is used to

I agree with all of this in principle, but there is an open problem 
with putting in a MUST for using a FQDN into the text of 822bis:

There are currently beasties (offline mail clients that will get 
their addresses through DHCP, for example), that can't use their DNS 
host domain name as the RHS because they don't have one at the time 
of Message-ID generation. As you say above, that's fine and a valid 
reason for using a host name not being MUST. A solution for those 
folks that satisfies the uniqueness requirement would be, for 
example, that mail domains would guarantee 
"<email-address-LHS>.mid.<email-address-RHS>" as a unique RHS for 
such clients. However, there is no currently deployed infrastructure 
available to guarantee such a thing. (Personally, I think it would be 
a good thing to do, but it's not there now.) Given the lack of 
deployment, I can't see how the DRUMS document could require this, or 
any other similar algorithm.

I'm open for suggestions of what you think I can put a MUST next to 
in the document, but in the current deployed base, I'm at a loss to 
know what those words would be.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 3 Jun 1999 18:16:10 -0400 (EDT)

> any other similar algorithm.

It seems to me that these beasties could either allow the user to
configure in a valid fully qualified name, or leave it up to the
server they submit messages to to generate Message-IDs, or some other
strategy, as appropriate to their situation (i.e. these are
suggestions, they don't both apply well to every situation, but some
reasonable strategy can be invented for any occasion).

It further seems to me that these beasties, if they do not use some
strategy to get an appropriate fully qualified name into the RHS of
the Message-ID, are already "nonconforming" in a real-world sense, no
matter what we write.  If we avoid declaring them so, we're just
avoiding documenting an established reality that we're not interested
in changing.  We might as well say it.

[ And yes, that means an MS Exchange Server that is configured such
  that it does not know its domain name, but still uses the return
  value of gethostbyname() as its Message-ID RHS, is nonconforming.
  Such Message-IDs do exist, but when we see them, we immediately
  think "broken mail server software!".  Because it is broken. ]

This is really a done deal.  The time to argue this point is years in
the past.  Fully qualified RHS is the entrenched de-facto standard and
anything that doesn't follow that is broken.

  --  Cos (Ofer Inbar)  -- [email-masked] [email-masked]
  "Crashing waves of infuriating morons eroding the beach of my sanity"
    -- Rob Spence <[email-masked]>, 15 July 1996

---

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Jun 1999 16:46:16 -0700

On 6/3/99 at 6:16 PM -0400, Ofer Inbar wrote:

>configure in a valid fully qualified name...

Not acceptable. How are users to determine a FQDN that they have 
administrative control over?

>...or leave it up to the server they submit messages to to generate 
>Message-IDs...

Not acceptable. How do you get the Message-ID back so you can track 
the message?

>...or some other strategy, as appropriate to their situation (i.e. 
>these are suggestions, they don't both apply well to every 
>situation, but some reasonable strategy can be invented for any 
>occasion).

I'm not convinced you can invent any strategy that doesn't involve 
some sort of other infrastructure (i.e., requiring certain reserved 
domains in the DNS, or some other way of getting a unique RHS to use).

>the Message-ID, are already "nonconforming" in a real-world sense, 
>no matter what we write. If we avoid declaring them so, we're just 
>avoiding documenting an established reality that we're not 
>interested in changing.  We might as well say it.

There is no question that these implementations are at least 
potentially, if not actually, broken. I don't want to argue that this 
state of affairs is acceptable or something that we want to continue. 
Declaring them either conforming or nonconforming doesn't change the 
reality one way or the other.

Unfortunately, the reality is that these implementations have *no 
possible way at this moment in time* to implement a MUST: There is no 
strategy that an implementor of one of these clients can use right 
now to *guarantee* a unique authoritative RHS, and it would be 
disingenuous to claim that a class of clients that exist today MUST 
do something to conform that they cannot possibly do.

I think it is imperative that we write an RFC to codify a way to get 
reasonable RHSs to Message-IDs. I think without such an RFC, any 
formal MUST in 822bis is unreasonable.

pr

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Jun 1999 17:02:08 +1000

Date:        Thu, 3 Jun 1999 16:46:16 -0700
    From:        Pete Resnick <[email-masked]>
    Message-ID:  <[email-masked]>

  | Not acceptable. How are users to determine a FQDN that they have 
  | administrative control over?

How do they determine it for their From: header?    To get a FQDN that
would work for this purpose (assuming a host based FQDN is needed) all
that should be required is to take the domain name from the e-mail
address that will be used, create a sub-domain of that based upon whatever
local networking identification is available to the host (or its local
idea of its host name, or its serial number, or some part of its MAC
address if it has one) and make a sub-domain of that based upon some
kind of product identification (eudora4.1234534.qualcomm.com perhaps
for you).  Since that info is time senstitve in some environments,
the host id part might be reused (eg: on appletalk) the local part
should embed the time of the message (but that is most likely going to
happen one way or another anyway).   Including the product name in the
RHS means that the method it is embedded doesn't matter, as long as
that product is consistent in how it does that.

  | I'm not convinced you can invent any strategy that doesn't involve 
  | some sort of other infrastructure (i.e., requiring certain reserved 
  | domains in the DNS, or some other way of getting a unique RHS to use).

The latter - and I don't believe it is that hard.   We could even invent
a special case token that is extremely unlikely to be used anywhere, and
make that be the first level subdomain of the e-mail address (0O0 perhaps)
generating eudora4.1234534.0O0.qualcomm.com - just in case you don't want
to presume that qualcomm.com doesn't have an existing domain
1234534.0O0.qualcomm.com which might have a eudora4 sub-domain which
might be generating message-ids using just the domain name.

I see you already seem to be using something akin to this in your mail,
given that your mesage ID has ... dhcp990531114138.qualcomm.com on the
RHS.   Of itself, I doubt that's quite the perfect solution, but it is
certainly a long way along the track to it.

  | There is no question that these implementations are at least 
  | potentially, if not actually, broken. I don't want to argue that this 
  | state of affairs is acceptable or something that we want to continue. 
  | Declaring them either conforming or nonconforming doesn't change the 
  | reality one way or the other.

No, but declaring what the implementations should be doing will assist in
moving the world towards that eliminating these problems.   Making
correct conformance an option makes it too easy to throw up your hands
and say "this looks too hard, the standard knows it can be too hard, and
allows me to 'cheat' if I have to, so I will".

  | Unfortunately, the reality is that these implementations have *no 
  | possible way at this moment in time* to implement a MUST: There is no 
  | strategy that an implementor of one of these clients can use right 
  | now to *guarantee* a unique authoritative RHS, and it would be 
  | disingenuous to claim that a class of clients that exist today MUST 
  | do something to conform that they cannot possibly do.

I don't think this is true.   An easy example is the exchange method that
has been much discussed.   Microsoft can easily assign one of their own
domain names, embed that in every copy of the application they ship, and
continue making their unique local parts using the uuid scheme, and
everyone will be happy.    I fail to see what makes this a method that
any other implentor can't just copy.

  | I think it is imperative that we write an RFC to codify a way to get 
  | reasonable RHSs to Message-IDs. I think without such an RFC, any 
  | formal MUST in 822bis is unreasonable.

I disagree with both parts.   We don't need "a" way to get reasonable
RHSs, as long as the RHS identifies the algorithm one way or another
("as in the algorithm used by eudora on the host named ..." (or with
address, or whatever) or "as in the algorithm defined for microsoft
exchange version N") how that is achieved is not important.  It doesn't
have to be defined.   Unless it really was impossible to do this correctly
(rather than just simpler not to bother) I think a MUST is entirely
reasonable.  I don't believe it is impossible, just sometimes difficult.

kre

---

From: Brad Knowles <[email-masked]>
Date: Fri, 4 Jun 1999 11:16:56 +0200

At 2:56 PM -0700 6/3/99, Pete Resnick wrote:

> their addresses through DHCP, for example), that can't use their
> DNS host domain name as the RHS because they don't have one at
> the time of Message-ID generation.

	The RHS could alternatively be an IP address, or a static label 
that is provably owned by the entity that either wrote the software 
(e.g., something like "version.product.unit.company.example", or 
whatever they care to create for their programs, so long as they're 
within the "company.example" domain which is clearly owned by them), 
or which is using the software in question.

	So long as the RHS satifies one of the above, then that should be 
sufficient to qualify the context in which the LHS was generated.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin      Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jun 1999 03:09:04 -0000

I'm reminded of the situation with network MAC addresses---which, unlike
Message-IDs, are a disaster if they're not unique.

According to Terje Mathisen, it was originally proposed that these
addresses be generated randomly. ``This suggestion was vetoed,'' he
says, ``with the result that manufacturing snafus have produced many
cards with unintentionally duplicated MACs.''

Brad Knowles writes:
> The RHS could alternatively be an IP address,

Here we see a typical snafu. In reality, for several obvious reasons,
message-creating software can't safely use the local IP address.

---Dan

P.S. Some messages to DRUMS are being massively delayed by the broken
cs.utk.edu mail system. Am I the only person who finds it absurd that
the IETF's mail working groups don't have reliable mailing lists?

---

From: Keith Moore <[email-masked]>
Date: Sat, 05 Jun 1999 23:37:39 -0400

> the IETF's mail working groups don't have reliable mailing lists?

the system isn't broken.  it's just filtering mail that looks like spam.
such mail gets dumped into a mailbox and waits for a postmaster to approve 
it if it's really on target for the list.

one of several reasons that mail might "look like spam" is if its From 
address isn't immediately verifiable.  it appears that dns queries to 
the domain cr.yp.to often time out (if they're not already in the cache)
and hence must be retried later.  so your mail in particular often ends 
up in the "potential spam" mailbox.  normally such mail gets reviewed
frequently during daytime hours; it happens that the person who usually
does this is out-of-town this week and I'm having to sub for her.
(actually, we're both out of town next week, so "moderation" will
take longer)

this is the best strategy I've found for (a) keeping the signal-to-noise
ratio high (or at least minimizing noise due to spam), while (b) still 
allowing anybody to post (e.g. whether on the list or not) without 
jumping through hoops.

so...it's not a bug, it's a feature!

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jun 1999 06:09:20 -0000

Context: DRUMS is an IETF working group dealing with Internet mail. The
DRUMS mailing list, [email-masked], has a history of mail loss and
other reliability problems.

In the latest episode, some messages to the mailing list---including at
least two of mine---were placed into a holding area pending review by a
cs.utk.edu postmaster.

Keith Moore, list administrator and former DRUMS chair, writes:
> it appears that dns queries to the domain cr.yp.to often time out

Other people don't have this problem, Keith. Perhaps your homegrown
``anti-spam'' software is flaky. Perhaps your network is flaky.

But this is beside the point. The correct response to temporary problems
is to TRY AGAIN LATER. Where did you get the idiotic idea that it would
be better to put the message on hold and wait for human intervention?

If retries are too complicated for your software, you shouldn't accept
the mail in the first place. The remote SMTP client will try again later
if you send it a 4xx code.

> it's not a bug, it's a feature!

I can't believe that someone who deliberately runs such a fragile mail
system would have the nerve to tell other people how mail should work.

---Dan

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Jun 1999 03:05:20 -0400

Dan,

your messages to the drums list were presumably sent to the
moderator because the spam filter could not immediately verify 
the validity of your return address.

we have found this to be an incredibly effective heuristic for
detecting spam sent to our mailing lists, and the inconvenience
to senders of having their messages delayed (usually only a few
hours) until the moderator can read them is far outweighed
by the benefit of virtually eliminating spam from the lists.

we considered having the spam filter report tempfail to the 
MTA in cases where the sender's address could not be immediately
verified, so that the MTA could retry delivery later.  but 
when we analyzed the traffic we realized that such a policy 
would invite denial-of-service attack from spammers (who, 
experience indicates, will stoop to anything).  especially given the 
low ratio of false positives, it made more sense to have a human 
moderate the list.

so we concluded that having an effective spam filter was more 
important than having absolutely immediate delivery of messages.

Keith

p.s. we could make the filter even better by having it moderate all
messages containing the word 'asinine'  since such messages
are highly unlikely to be appropriate for ietf mailing lists.

---

From: [email-masked] (Kai Henningsen)
Date: 06 Jun 1999 19:02:00 +0200

> do something to conform that they cannot possibly do.

Oh, there certainly is. Doing a unique enough LHS under those conditions  
is what is challenging.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 06 Jun 1999 19:01:00 +0200

> any other similar algorithm.

Well, let's assume there is a copy of Eudora running in a situation where  
it can't determine a good FQDN for it's host.

Presumably it *does* have access to a good email address, because without,  
there's not much it can usefully do anyway.

Now, how to get a usable message id from that?

Well, what about <[something unique on that host][email-masked] 
id.qualcomm.com>? That's a perfectly good FQDN.

> know what those words would be.

The currently deployed base isn't going to change their behaviour no  
matter what gets put into the spec. And what it does is either going to  
work, or going to break, again irrespective of what we write into the  
spec, given we don't intend to tell anyone to reject the message ids  
generated by the installed base, and don't intend to create message ids  
incompatible with the installed base.

So it's really a non-issue.

We're really talking about what new software should do.

Given all that, here's some text:

    If determining the local host name or ip address is too hard, a FQDN
    under the control of the software author could be used. The local part
    still needs to avoid collisions between all users of that FQDN.

MfG Kai

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 6 Jun 1999 22:02:59 -0400

> if you send it a 4xx code.

If the remote client is an NT server running Microsoft SMTP without an
update Microsoft issued in March, it will try again immediately if you
send it a 4xx code.  "Immediately" means up to 6 times per second for
the cases that we've logged here.  The first report of this on bugtraq
was of a case of an NT server attempting to deliver a message 200,000
times in one day.

We had cases involving tens of thousands of attempts in our own logs
but had attributed them to intentional denial of service attacks on
our mail servers.  They stopped happening when we began returning 5xx
error codes.

That, BTW, was Microsoft's suggestion too.

(To Microsoft's credit, they promptly acknowledged the problem and
fixed it - but there are lots of NT systems out there that have not
had the update applied.)

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY, 1-800-910-6671 (voice)
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
	  Oldest Internet service based in the 518 area code

---

From: David Mayne <[email-masked]>
Date: Sun, 6 Jun 1999 23:18:17 -0400 (EDT)

> was of a case of an NT server attempting to deliver a message 200,000

I am glad that you have brought this up, as my previous questions
on [45]52 response codes have been prompted by Microsoft SMTP
MTA mailbombing Mindspring's customers in a very similar
fashion. Mindspring has been using a 552 code for years for
over mailbox full violations, but prior to 6 months ago, this
code was only used by the local delivery agent, and a bounce
sent back  - we now have a policy not to accept mail for users 
who we know are over the quota in the smtp session at the time
of RCPT. The only client that has problems with this is Microsoft's 
SMTP MTA. Microsoft's attack on our customers goes as follows:

MAIL FROM: [email-masked]
250 [email-masked]... Sender ok
RCPT TO: [email-masked]
552 quota violation
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
[...]
250 rlmc41.bs3.37kbi17 Message accepted for delivery
MAIL FROM: [email-masked]
250 [email-masked]... Sender ok       
RCPT TO: [email-masked]
552 quota violation
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok      
RCPT TO: [email-masked]
250 <[email-masked]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
[...]
250 rlmc88.bs3.37kbi17 Message accepted for delivery

This Microsoft SMTP MTA will continue mailbombing
the recpients who are not over quota until their 
mailboxes fill up to, and all are returning 552 codes
- finally, the attack stops (or our admins notice the
attack, and null route the offending Microsoft SMTP
MTA). In cases, our customers have had over 5000
messages in their mailbox, and are denied service
to getting any more mail.

Keith Moore stated the following concerning 452 and
552 error codes in a recent response to my questions:

>imho, "too many recipients" should always be 452 code.
>the 552 code would normally be interpreted by the sender as  
>"completely stop trying to deliver this message to this recipient"
>which almost certainly isn't correct behavior for a "too many recipients"
>condition.

and:

>if a client gets a 4xx in response to RCPT, it should treat it as
>a temporary failure to deliver that message to that recipient,
>and it may retry later if it wishes.  if it gets a 5xx in
>response to RCPT it should treat it as a permanent failure
>to deliver the message to the recipient. it should normally
>bounce the message, but it should definitely not make further
>attempts to deliver the message after that.
>
>however, a 452 code in response to RCPT should probably be interpreted
>by the client as "stop trying to send RCPTs in this session" -
>so the client would handle that recipient and all remaining
>recipients for that messages as if they were temporary failures.
>
>I would treat 552 should as a special case and handle it identically
>to 452.

As such, according to what Keith states above, Microsoft should not
be retrying the same sequence of recipients over and over in the
same session with either a 452 or 552 code, which is clearly being
violated by the incident outlined above. My question now, is 452
sufficient for Microsoft to stop mailbombing other recipients when
one of the recipients in the list happens to be over their quota,
given the fact that 4xx codes have also proved to be problematical
with Microsoft's SMTP MTA in the past. I have no problems changing
to a 452 code if this solves the problem, and spares our customers
the grief that they have been experiencing from this problem.

> That, BTW, was Microsoft's suggestion too.

Well, see above, 552 is troublesome for us, at least on RCPT.

> fixed it - but there are lots of NT systems out there that have not

The mailbombing incidents Mindspring has been experiencing have 
not an everyday occurence, and we receive millions of messages
per day, so the sequence above was somewhat hard to track down.
Once we did so, I contacted David Lemson, SMTP Program Manager
for Microsoft, and presented him with evidence from our logs of 
the above problems.  He responded that he got the developers to look 
into the issue, and then replied, stating that "We believe our
servers are doing the appropriate thing." He then made an appeal
to the drums-10 draft, and stated "we are abiding by the suggestion 
that they give (we treat a 552 as if it were a 452)."

If this is how Microsoft treats a 452 code (i.e., continuing
issuing RCPT's and DATA over and over again to the same list
of recipients), then I'm wondering what good it will do for
us to change to a 452 code for quota violations on RCPT.
We could return a 550 code (troublesome because sendmail will
send out a bounce with the subject stating "User unkown", 
which is a problem for our support department) to stop our
customers from being bombed, or perhaps some other 4xx code
- but, how will Microsoft SMTP server respond to any other
4xx codes on RCPT ? Clearly, even if we are not returning 
the appropriate code for quota violations (552), the behavior 
of their MTA under these circumstances is still inappropriate 
according to my reading of updt-10 and Keith's observations 
noted above. 

In light of the above issues, does anyone have any suggestions
on how to deal with Microsoft's SMTP MTA, since Microsoft
does not think this is a problem ? My purpose here is not
to grill MS, but to stop our customers from being unfairly
bombed by MS's MTA. We have *never* had this issue with any
other MTA's - sendmail, qmail, postfix, etc will not repeat
the same delivery sequence over and over again when getting
a 552 code on RCPT. 

I have responded privately to David Lemson at Microsoft,
disputing their contentions that their SMTP MTA is behaving
appropriately according to drums-updt-10, but have not 
recevied any response in over a week, hence my sharing this
issue with the drums list.

Thanks,

David
[email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Jun 1999 21:35:02 -0000

Dick St.Peters writes:
> send it a 4xx code.

As if common sense weren't enough: RFC 1123 specifically requires that
SMTP clients delay before trying again. I wonder how Microsoft managed
to screw this up.

Anyway, this doesn't justify Keith's asinine ``put the message on hold
and wait for human intervention'' method of handling temporary failures.
If Keith has a problem with a Microsoft host, then he can deal with it
without setting up a fragile mail system that screws up other people's
messages.

---Dan

---

From: [email-masked]
Date: Mon, 07 Jun 1999 19:01:02 -0400

> SMTP clients delay before trying again. I wonder how Microsoft managed

And screw up it did.  One of my machines got pounded 123,000+ times in 36
hours over the weekend.

> without setting up a fragile mail system that screws up other people's

Oh pray tell, wonderful wise guru of SMTP, how does one determine remotely
that the remote host is Microsoft, and should be handled differently, instead
of simply saying "this looks suspicious, have it checked out"?  Remember -
it's contacting YOU , so you can't intuit based off the 220 header you're sending
to them on each connection.

I'd also be interested in knowing just how bulletproof you want a mail system
to be - how many hundreds of thousands of bounces/errors should it be overdesigned
to handle so it doesn't count as 'fragile'?  Remember that such levels of
excess capacity *cost money*, and sometimes it *is* cheaper to let a human sort
it out.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Mon, 07 Jun 1999 19:45:50 -0400

> without setting up a fragile mail system that screws up other people's

I really hate rubbing salt in things, but..  RFC1891 through RFC1894 are
for building less fragile mail systems, providing machine-parsable replies
that the software can act on without human intervention.  The following notice
I got *requires* human intervention.

> Hi. This is the qmail-send program at koobera.math.uic.edu.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.

This *after* qmail had added a 'Delivered-To: [email-masked]' to the original
body, and leaving no other hint what address failed.

I'm sorry Dan.  I really can't have much sympathy for your position.
As postmaster for a large Listserv site, I see literally 200 to 300 bounces
a day - and the one from my previous posting ranks very high up the list of
'least likely to be machine parseable'.

And that's not the way to build non-fragile, robust mail systems.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 03:19:56 -0000

[email-masked] writes:
> One of my machines got pounded 123,000+ times in 36 hours over the weekend.

I understand your annoyance at the waste of log space, but you must have
an incredibly slow SMTP server if one connection per second constitutes
``pounding.''

> Oh pray tell, wonderful wise guru of SMTP, how does one determine
> remotely that the remote host is Microsoft, and should be handled
> differently,

Dumb question. What's annoying you is not that the SMTP client is from
Microsoft. What's annoying you is that the SMTP client is making lots of
SMTP connections where it isn't getting anything done. You can check for
that, and take appropriate action, without hurting other clients.

> I'd also be interested in knowing just how bulletproof you want a mail
> system to be

As stated in http://pobox.com/~djb/proto/im/responsibility.html, under
``Quality issues'':

   Sometimes the first attempt to deliver a message is stymied by a
   temporary problem such as a network outage or a full disk.
   High-quality mailers do not give up on delivery after a single
   temporary failure; they wait for a while and then try again. They
   give up only if the ``temporary'' problem persists for several days.

I'm astounded that you could refer to such a fundamental feature of the
Internet mail system as ``overdesign.'' The overall costs are minor, and
the reliability benefits are tremendous.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 04:34:52 -0000

See http://pobox.com/~djb/docs/copies.html if you're curious about the
bounce message that has gotten Kletnieks so upset.

[email-masked] writes:
> RFC1891 through RFC1894 are for building less fragile mail systems,

That's what they were _intended_ to do, but intent isn't enough when it
isn't backed up by solid engineering.

RFC 1891 is an absurdly complicated link-level protocol, unsupported by
most MTA authors and useless for standard multidrop POP mailboxes. Its
misguided notification guarantee, which is what forced the complexity in
the first place, appears to have been destroyed by sendmail.

RFC 1892 and RFC 1894 aren't as ludicrous as RFC 1891, but they're still
unnecessarily difficult to parse.

Fortunately, all of these RFCs have been rendered obsolete. The big
problem that motivated them---namely, the difficulty of identifying the
subscriber for each mailing-list bounce---has been eliminated by VERPs.

> 'least likely to be machine parseable'

In fact, qmail's bounce messages follow a documented, easy-to-parse
format that has around just as long as RFC 1894. Several independent
parsers have been deployed. See http://pobox.com/~djb/proto/qsbmf.txt
for a description of the format and a comparison with 1892/1894.

---Dan

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 10:11:01 +0200

> subscriber for each mailing-list bounce---has been eliminated by VERPs.

	Yes, everyone must bow to the one and only SMTP God; the one and 
only person who actually understands impossibly complex things like 
RFCs, systems engineering, communications, and the entire Universe.

	Everyone, please turn to your King Dan Bible, in the Book of Dan, 
Chapter Dan VI, Verse 21.3.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 09:55:34 +0200

> an incredibly slow SMTP server if one connection per second constitutes

	Well, when one copy of that message is delivered to all 
recipients (save those that have full mailboxes, etc...) each and 
every second, I can understand why there would be a problem.

	Even you must admit that you are limited by your local delivery 
agent, and if you were to deliver a thousand copies of the same 
message (or even just a hundred) for each and every second of hours 
upon hours on end, your mail system would probably slow down to that 
of a scum sucking snail -- that's assuming that it stays running at 
all.

> that, and take appropriate action, without hurting other clients.

	What's annoying is that the same message is being successfully 
delivered time after time after time after time to all the other 
recipients that aren't currently having any problems, until such time 
as all recipients have full mailboxes, and then the message as a 
whole bounces.

	I think I've decided that we should all run nmap and queso on our 
mail servers, and if the connecting machine is a Windows NT box, we 
should refuse to talk to it.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 8 Jun 1999 12:50:17 +0100 (BST)

> the reliability benefits are tremendous.

Is there any sort of standard algorithm for determining waits between
subsequent attempts? (thinking of a poor analogy with TCP backoff
here.)

Tying in some sort of intelligent calendar function ('it's Friday
night there, it's hosed, I may not be able to send to Monday at the
earliest - hang on, Monday is Memorial day, better make that Tuesday,
so I'll spread x attempts over that time') strikes me as a possibly
neat optimisation, speaking from recent experience.

L.

'they wait for a while and then try again' is always a good research area.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Jun 1999 14:16:54 +0200

> subsequent attempts? (thinking of a poor analogy with TCP backoff

	I'm not aware of any.  This is one of the areas where I believe 
that Wietse Venema has made at least some initial improvements, by 
starting with my suggestion that he use TCP-style bounded exponential 
backoffs.

	This is one *major* advantage of postfix over any other MTA I am 
personally acquainted with, although I won't get into specifics that 
might be misinterpreted as personal attacks.

> neat optimisation, speaking from recent experience.

	Although perhaps an interesting research topic, this would 
require some knowledge of where the remote end is physically located.

	Being over here in Belgium and having had some recent problems 
with a Usenet news satellite feed company that is located in the UK, 
I am well aware of what can happen when there is a problem and one 
side has a bank holiday while the other doesn't.

---

From: Philip Hazel <[email-masked]>
Date: Tue, 8 Jun 1999 13:47:15 +0100 (BST)

> starting with my suggestion that he use TCP-style bounded exponential 

Exim allows you to configure a combination of fixed-length and bounded 
increasing-length retry times. For example,

F,2h,15m; G,16h,1h,1.5; F,4d,8h

means "try every 15 minutes for 2 hours; then start at 1 hour and 
increase the interval by a factor of 1.5 until 16 hours have passed; 
then try every 8 hours up to 4 days; then bounce".

Retry rules like this can be predicated on a number of factors including 
domain and type of error. The above rule is our default. For very large
ISPs such as aol, I find it appropriate to configure more frequent
retries (after 2 hours), because they are seldom off the air for very
long.

Exim's retry rules work per host (strictly, per IP-address), not per
message, for typical host errors such as connection refused and
connection timeout. Thus, new messages don't get tried until the host's 
retry time arrives.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jun 1999 11:12:37 -0400

poor analogy.  when we suspect that a message may be spam we don't want 
to handle it in the same way as a network outage or full disk.  
in particular:

- we aren't willing to tolerate the same amount of max delay before
  deciding whether to send the message to the recipients.  we wait
  three days before giving up attempting to relay a message when the
  relay attempt fails for temporary reasons. suspected spam, on the 
  other hand, typically gets reviewed within a few hours.

- if we do decide that the message is spam, we want to discard it
  silently.  we don't want to return the message to the sender.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Jun 1999 15:44:20 -0000

Lloyd Wood writes:
> subsequent attempts?

Not really. RFC 1123, section 5.3.1.1, points out some of the issues for
SMTP clients to consider, but it doesn't go into much detail, and it's
missing some features that are now considered essential for large sites.

qmail normally tries a message after 0 minutes, 7 minutes, half an hour,
an hour, etc., slowing down to a total of about 40 attempts in one week.
The precise algorithm for remote hosts is as follows:

   * Each message has an independent quadratic retry schedule, measured
     in seconds from when the message was queued: 0, 1, 4, 9, 16, etc.

   * When a message delivery begins, the next attempt is scheduled for
     20 spaces in the retry schedule after the current time. Note that
     this is not ``when a message delivery ends,'' nor is it ``after the
     previously scheduled time''; those don't work as well under load.

   * If a message delivery begins after more than one week (by default),
     temporary failure is treated as permanent failure. Note that each
     delivery will be tried at least once, even if the load is so
     extreme that the first try is delayed for more than a week.

If two connection attempts to an IP address time out, separated by at
least two minutes, with no intervening successful connections, then
connection attempts to that address are skipped during the next 60-90
minutes.

(What actually happens is that connection attempts are skipped with
probability 31/32 after 3840 seconds, probability 30/32 after 3904
seconds, etc. This gradual change works much better than a sudden cutoff
under high loads.)

Some mailers opportunistically bombard a host with deferred messages as
soon as the host comes back online. qmail doesn't; each message waits
until the appropriate retry time.

---Dan

---

From: [email-masked]
Date: Tue, 8 Jun 1999 14:19:20 -0600

> Chapter Dan VI, Verse 21.3.

Even better, turn to the book of procmail(1). If we ignore him he won't
go away, but at least our stress level will decrease.

-- 

The two most common elements in the universe are Hydrogen and stupidity.
					-- Harlan Ellison

---

From: Jacob Palme <[email-masked]>
Date: Wed, 9 Jun 1999 13:17:28 +0200

> Not acceptable. How do you get the Message-ID back so you can track

The new message-submission protocol, which is to replace
SMTP for message submission, could include functionality to
return the Message-ID back. In fact, why not include
functionality to inform the mail client of *all*
modifications made by the submission MTA in the new
submission protocol?
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Jun 1999 19:45:57 -0000

People who say things like ``the spam filter copied each message to /tmp
... insufficient resources ... you will need to resend'' should not be
running IETF mailing lists.

There are other people who are perfectly happy to run the lists---people
who are using reliable mail software that deals with temporary failures
properly.

Keith Moore writes:
> we wait three days before giving up attempting to relay a message when
> the relay attempt fails for temporary reasons.

Keith claims here that he ``isn't willing to tolerate'' such delays from
his anti-spam system. He claims that a message ``typically gets reviewed
within a few hours.''

But that's simply not true. Out of 1000 recent DRUMS messages:

   * DRUMS message 5724 was delayed for seven days.
   * DRUMS message 5726 was delayed for two days.
   * DRUMS message 5790 was delayed for two hours.
   * DRUMS message 5795 was delayed for a day.
   * DRUMS message 5796 was delayed for seven minutes.
   * DRUMS message 5819 was delayed for a day.

Two of those were from eng.sun.com. I suppose Keith thinks we should
blame the DNS service at eng.sun.com? Sorry, Keith, but the problem is
YOUR UNRELIABLE MAIL SYSTEM!

(Note that three days isn't enough to handle long weekend outages. RFC
1123 says ``the give-up time generally needs to be at least 4-5 days.'')

> when we suspect that a message may be spam we don't want 

It is idiotic to respond to a single temporary failure by diverting
messages to a sysadmin.

I don't care what Keith does to messages that really _are_ spam. But I
am not willing to accept collateral damage from his anti-spam software.

---Dan

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Jun 1999 17:49:24 -0400

Dan,

I'll change the spam filtering software so that if the 
From address is a list subscriber, it will bypass the 
portion of the spam filter that tries to check the address.
Perhaps that will alleviate your concerns.

Keith

---

From: Matt Curtin <[email-masked]>
Date: 10 Jun 1999 23:32:39 -0400

>>>>> On 10 Jun 1999 19:45:57 -0000, "D. J. Bernstein" <[email-masked]> said:

I'm not going to get sucked into a debate here.  But this is far too
silly to let go completely unanswered.

Dan> Two of those were from eng.sun.com. I suppose Keith thinks we
Dan> should blame the DNS service at eng.sun.com? Sorry, Keith, but
Dan> the problem is YOUR UNRELIABLE MAIL SYSTEM!

Problems in the middle could well cause this sort of behavior (DNS
lookup failure).  Last time I checked, eng.sun.com isn't getting any
special treatment that would cause its DNS to be 100% reliable from
every host on the Internet.  Or perhaps I missed something...

I think that you're jumping to conclusions a little too hastily.  The
only data you have is the amount of time it takes for Keith's system
to accept a message from remote.  That isn't enough data to debug the
problem.  I know you know that, and I'm amazed that you're willing to
go out on that limb, knowing that almost every one of us here is quite
adept at handling a chainsaw.

I fail to understand why you feel the need to shout, to question the
competence of the area director, and to complain to IETF because your
comment to the DRUMS list was delayed a little bit.  And to do so all
at once seems, well, asinine.

Dan, we all want the Internet to work reliably.  That's why we're
here.  Screaming won't fix what's broken.  The world will continue to
work if we have to wait a few precious moments for your words of
wisdom.

One one hand, I'm actually sorry to see that Keith is modifying his
system because of your tantrum.  That certainly isn't a good idea from
the perspective of behavior modification...  On the other hand, I too
would have chosen (and in fact have chosen) another method of handling
spam and do not want to see spam handling techniques degrade the
quality of service.

But behaving in a more silly manner than Keith's spamtrap strikes me
as a strange way to encourage him to find a better solution.

-- 
Matt Curtin [email-masked] http://www.interhack.net/people/cmcurtin/

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Jun 1999 05:45:05 -0000

Matt Curtin writes:
> to accept a message from remote.

Wrong. Far more information is available. Message 5795, for example, was

   * received from playground.sun.com by cs.utk.edu one Thursday at
     14:29:07 -0500;

   * diverted by Keith's anti-spam system into a holding area, where it
     sat, waiting for human attention, without being retried; and

   * reinjected by moore@localhost the next day at 14:10:17 -0500.

This is one of several messages I pointed out before. You could have
looked in the archive rather than making a fool of yourself.

Keith admits that this is how his system reacts to a momentary network
outage. How can he not understand that this behavior is wrong?

> comment to the DRUMS list was delayed a little bit.

At least fourteen messages from several people have been delayed, in one
case by an entire week. At least two messages have been lost. If Keith
had pulled these stunts at an ISP, he would have been fired long ago.

---Dan

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:29:19 -0700

>and wait for human intervention'' method of handling temporary failures.

In fact, placing a message in a queue for human review is a common, 
accepted, and very useful technique.  One should note that the particular 
case being reported is not just a random, temporary error, but an error 
occurring during a vetting mechanism.

ANY failure (other than local machine crash or network access error) during 
such vetting is suspicious, so that it in fact makes sense to move the mail 
out of regular processing.

d/

ps.  While one is discussing peculiar ways to run mail systems, it might be 
worth noting that a peculiar way to participate in open discussions is to 
have your SMTP server reject (bounce, i.e., return) mail from one or 
another of the participants.  That, of course, is not a theoretical 
example, since Dan has configured his server to reject my mail; he won't 
see this comment.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:32:12 -0700

At 10:11 AM 6/8/99 +0200, Brad Knowles wrote:
	Everyone, please turn to your King Dan Bible, in the Book of Dan, Chapter 
Dan VI, Verse 21.3.

Tsk. Tsk, Brad.  Surely you meant King David...  (Just so long as no one 
says it's a crock.)

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Jun 1999 00:34:52 -0700

>Perhaps that will alleviate your concerns.

Keith,

Given the ease of spoofing From fields, why would you want to open that 
large a door for spamming to come through?

d/

---

From: Dave Sill <[email-masked]>
Date: Fri, 11 Jun 1999 07:59:07 -0400 (EDT)

Dave Crocker <[email-masked]> wrote:
>another of the participants.

That *would* be peculiar if Dan did that, but he doesn't. If a message
is sent both to a list he's on *and* directly to him, he bounces the
copy that was sent directly. I, too, find it annoying to receive
multiple copies of messages unnecessarily. I've just been too lazy to
implement Dan's approach. Some people complain about problems, others
fix them.

>That, of course, is not a theoretical example, since Dan has
>configured his server to reject my mail; he won't see this comment.

He saw it. You apparently didn't bother to read the bounce
message. Could this be another knee-jerk anti-djb reaction?

-Dave

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Jun 1999 08:06:32 -0400

> large a door for spamming to come through?

[reply list trimmed]

the only change to the spam filter is that a From address that's on
the list is presumed to be valid without actually doing the DNS 
lookup and checking via SMTP.  the other checks that the spam
filter does are still in effect.

Keith

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 11 Jun 1999 14:34:02 +0100 (BST)

On Fri, 11 Jun 1999, Dave Sill wrote:

> multiple copies of messages unnecessarily.

I find it interesting that Dan bounces the direct copies, while only
accepting the possibly-delayed copies which go through someone else's
listserver he grumbles about.

Using the quicker-to-arrive (usually direct) copies and silently
discarding the later-to-arrive (usually listserver) copies as
duplicates (based on message-ID) strikes me as the preferable strategy
leading to more robust and timely mail for the user, but then I don't
have an agenda.

> I've just been too lazy to

and some people fix what they see as problems just to give them an
opportunity to complain about other things they see as problems.

L.

has always been amazed by qmail's _polite_ messages. Who wrote those?

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 11 Jun 1999 09:01:34 -0500

> who are using reliable mail software that deals with temporary failures

After we subtract those who quickly resort to words like "asinine"
and "idiotic" in what should have been a technical discussion,
control-freaks and those mainly interested in self-aggrandizement,
how many candidates are left?

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Jun 1999 10:06:00 -0400

> example, since Dan has configured his server to reject my mail; he won't 

I'm also on the list of people Dan has put into the "reject in SMTP"
list. Among other things, it makes it impossible to try to send a
comment in private to him.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 11 Jun 1999 10:09:56 -0400

Dave Sill <[email-masked]> writes:
> copy that was sent directly.

No, that isn't what happens. If I send a private comment to Dan OR a
comment cc'ed to the list, I get bounced. I'm on his "special people"
list. Presumably he still sees the copy sent to the public mailing
list, but I have no way to know that.

> message. Could this be another knee-jerk anti-djb reaction?

It is difficult, I must admit, not to have automatic anti-djb
reactions. Given his rather poor public behavior on a number of
occasions (everyone remember his recording "off the record" telephone 
conversations during the lovely IDENT discussion some years back?),
his immediate resorts to name calling, his transparent attempts to
derail IETF process, and his overall demeanor towards anyone who has
the temerity to disagree with him in public, this tendency on the part 
of many must be understandable.

Perry

---

From: Martin Hamilton <[email-masked]>
Date: Mon, 14 Jun 1999 12:05:56 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Lloyd Wood writes:

| Using the quicker-to-arrive (usually direct) copies and silently
| discarding the later-to-arrive (usually listserver) copies as
| duplicates (based on message-ID) strikes me as the preferable strategy
| leading to more robust and timely mail for the user, but then I don't
| have an agenda.

I used to do this (using procmail's duplicate message ID filtering),
but discovered that message IDs that start out the same sometimes end
up different when relayed through broken gateways or list managers.

So, I hacked some code up to stamp each message with the MD5 of its
contents - as per draft-hamilton-content-md5-origin-01.txt - and
tweaked procmail to add an MD5 cache/filtering option in tandem to 
the message ID one.  Used extensively with Exim, lightly tested with 
sendmail.  Caveat emptor :-)

Grab it from: <URL:http://www.net.lut.ac.uk/~martin/antispam/>

Martin

---

From: [email-masked] (Kai Henningsen)
Date: 14 Jun 1999 21:16:00 +0200

> subscriber for each mailing-list bounce---has been eliminated by VERPs.

Ah yes, the misfeature that means recognition of ezmlm/qmail mailing lists  
has to use completely different code than recognizing normal mailing  
lists.

But I shouldn't be surprised; ezmlm has already bitten me before with its  
incredibly baroque user interface (for example, it's the only thing that  
ever made me bump into an address length limit).

Personally, I consider this piece of software (mildly) abusive, both of  
the 'net and of the users.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 15 Jun 1999 09:38:00 +0200

[email-masked] (Perry E. Metzger)  wrote on 14.06.99 in <[email-masked]>:

> [email-masked] (Kai Henningsen) writes:
> I have to say that VERPs are not an altogether bad idea, although I

True. They're one way to do probes in the face of braindead software on  
the other end.

But they completely defeat optimizations at the place where they are  
needed most. Of course, Dan chooses not to believe in optimizations he  
didn't invent himself.

Of course, they still don't help with software that doesn't bounce to the  
envelope sender, which IME is by far the worst problem.

Especially when bounce means "send an error message that doesn't contain  
any clue about the original message".

I've delt with those. For example, for a time I got irregular mail from an  
Italian BBS that some user didn't exist there. In Italian. Of course, I  
had never sent any mail there. And though I tried to explain the problem  
several times, the sysop seemed unable to understand my problem.

MfG Kai

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Jun 1999 00:46:13 -0000

> has to use completely different code than recognizing normal mailing  

The problem is that you're abusing the envelope sender address. It is
not a permanent mailing-list identifier; it is a return path for bounced
mail. It is selected for the convenience of the mailing-list manager.

In contrast, the envelope _recipient_ address is controlled by the user.
Users running qmail have easy access to a large space of addresses, and
often subscribe to different mailing lists under different addresses.
This is simple and reliable; it doesn't matter what software is being
used to run the mailing list.

Another solution is a dedicated header field such as List-ID. This has
the virtue of being readily available to MUAs no matter how the message
is delivered. I expect it to become a standard MLM feature.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Tue, 22 Jun 1999 11:29:18 +1000

Date:        22 Jun 1999 00:46:13 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | often subscribe to different mailing lists under different addresses.
  | This is simple and reliable; it doesn't matter what software is being
  | used to run the mailing list.

It is effective only for users who know enough about mailers to
manage to handle address spaces in that way, which I doubt is the
majority.

And second, it doesn't work very well at all with lists that require
that messages to the list come from an address which is subscribed
to the list, unless the user manages to remember to manipulate their
From: address every time they send to the list (which some MUAs make
difficult at best).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Jun 1999 21:45:01 -0000

Robert Elz writes:
> require that messages to the list come from an address which is subscribed

That ``feature'' is a disaster. It doesn't work with sublists. It
doesn't work with newsgroup gateways. It doesn't work with web gateways.
It doesn't work with external digests. It doesn't work with discussions
that deliberately include contributors who aren't on the list. And, as
you noted, it doesn't work with users who have more than one address.

---Dan

---

From: Jacob Palme <[email-masked]>
Date: Thu, 24 Jun 1999 18:26:17 +0200

> you noted, it doesn't work with users who have more than one address.

DJB: It doesn't work with sublists.

JP: It does, if the check is done on the SMTP sender, and
if the sublist gives write permission to the SMTP sender of
the superlist.

DJB: It doesn't work with newsgroup gateways.

JP: Because newsgroups do not have any member lists, you
cannot check for membership before allowing writing.
Either, you will have to keep a non-news membership list,
or allow everything coming from news.

DJB: It doesn't work with web gateways.

JP: I am not clear of what kind of web systems you are
gatewaying too. But as long as the web system, which you
are gatewaying too, has membership lists, it can be made to
work.

DJB: It doesn't work with external digests.

JP: Why not? Just make the digest producer a member of the list.

DJB: It doesn't work with discussions that deliberately
include contributors who aren't on the list.

JP: Contributors from non-members have to be approved by
the moderator. If this is done, it will work, because the
moderator will be the SMTP sender of the submission to the
list.

DJB: And, as you noted, it doesn't work with users who have
more than one address.

JP: With LISTSERV, you can register people as members of a
list, but which do not get submissions sent to them. Thus,
a person with multiple addresses can register all his/her
addresses as members of the list, but let the list
distribute to only one of the addresses.