[Top] [All Lists]

Re: 2821bis chapter 2

2005-09-03 11:22:06

John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
--On Saturday, 03 September, 2005 00:46 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

I prefer the usual style of 2119 keywords with a reference.

The definitions of those terms are different in 2821 than in the
2119 usage, with 2821 following 1123 and related traditions.
The difference is significant.  Please review the DRUMS archives
if you are interested.

   I really don't think we can ask every reader to "Please review
the DRUMS archives".

   (I'm quite sure John Klensin is right about the difference: I
merely think it's asking entirely too much of the reader to apply
pre-2119 meanings in this document.)

   Alas, I don't know how much work would be involved in updating
to 2119 meanings...

* 2.3.4 (numerical addresses)

2821 said "discourged", now it's SHOULD NOT (better).  STD 10
had an obsolete idea of host numbers #<integer> in addition
to domain literals.

A leftover from pre-IP days, or at least prior to the
distinction between a network part and a local host part of an
IP address.

   Hopefully we have at least rough consensus this deserves to be

IMHO that paragraph needs more clean-up:

| Hosts are known by names (see the next section); they SHOULD
| NOT be identified by <address-literals> (see section 4.1.2).
| Other forms of numerical addresses are deprecated and MUST
| NOT be used.

I've put the forward pointer in.  DRUMS pretty much decided to
avoid cluttering the 2821 text detailing prohibitions and the
#<integer> form is prohibited in A.6.4.  So, unless others feel
strongly about this, I'm going to leave that last sentence out.

   I feel pretty strongly that a MUST NOT belongs here.

   That doesn't mean I expect to never see such violations. I mean
that folks _are_ going to be rejecting such nonsense and I'd like
to stop arguing how dreadful it is for them to do so.

   (Clearly, there will be ignorant folks configuring SMTP clients
with garbage HELO strings: I don't expect implementors to prevent it.
I just want it clearly legal to choose to reject such garbage.)

2.3.8 Originator [no new issue]

?  An "originating" system (sometimes called an SMTP
? originator) introduces mail into the Internet or, more
? generally, into a transport service environment.

That's a very tricky statement.  Internet mail is not limited
to SMTP, and SMTP is (in theory) not limited to the Internet.
How about this:

| An "originating" system (sometimes called an SMTP originator)
| introduces mail into the transport service environment
| defined by this document, i.e. SMTP in the Internet.

The tricky wording was intentional, given the gateway/relay
family of issues.  It may well be too subtle, but the suggested
replacement text, IMO, narrows things too much.  Comments and
suggestions from others solicited.

   I admit the distinction is probably too subtle for me to catch
it. I merely find Frank's text (marginally) more confusing.

At the end of 2.3.8:

[[Note in draft/Placeholder: There has been a request to expand

Yes, something about gateways acting as SMTP originator.  They
should not invent a Return-Path to the mail-originator, unless
they are also the MX and / or it's clearly in the best interest
of the mail originator.

This is tricky, and, again, more discussion is requested.  I
would suggest that, if the gateway cannot determine a reverse
path (not the header Return-Path, which can be supplied only by
the delivery MTA), then either

 (i) it has no business injecting the mail into the SMTP
     environment or
(ii) it is acting, not as a gateway, but as a submission server.

   I'm not sure our definitions of "gateway" and "submission
server" can be mutually exclusive.

   But I think here we need to dwell on "cannot determine".

   When we talk of a "gateway" we imply some difference in the
environment: thus we introduce a doubt whether there _can_ be a
"reverse-path" with the same meaning in both environments.

   We should not be demanding that the "gateway" find such a thing:
we should be asking the gateway to generate a useful return-path
to reach an entity capable of remediating errors which may occur.

   I also note that some folks want to attach a lot of baggage
when they say "submission server" -- so I'm not sure we're all
talking the same thing when we use that term.

   Trying to decipher what Frank said, he talks of "gateways
acting as SMTP originator" and his context appears to be how to
distinguish between "originator, delevery, relay, and gateway"

   I take that to mean Frank sees gateways as a combination of
"delivery" systems in one environment and "originator" systems
in another. (I'm not sure that is our intent in 2.3.8...)

   Beyond that, I guess Frank is concerned that if the gateway
"originates" an email with <return-path> being any domain for
which the management of incoming MX is different than the
management of the gateway, we've got a danger of abuse via
generated NDNs going to innocent parties.

   Frank has a good point there: if such NDNs come back through
the same gateway or a coordinated system, there clearly can be
enough information to properly direct them to a responsible
entity. Otherwise, it's really not clear.

   The situation actually is very similar to generic originators:
there may be very good reason to trust reverse-paths generated by
MUAs; but the _responsibility_ for the goodness of return-paths
belongs at the originating SMTP client. The difference in the case
of a gateway is that the reason to trust MUAs may be absent.

   In pre-2821 days, <reverse-path> actually carried the concept
of path of responsbility. We _might_ need to discuss whether 2821
threw out too much of the baby along with the bathwater... :^(

The fact that the mail originated on another system, in a different
format or protocol, is almost irrelevant to a submission server,
it presumably has, and follows, its own sender-authorized rules
about how to set the reverse path.

   Not all gateways can presume sender authorization of the rules
it follows. This has led to lenience which is now being actively
abused. :^(

Generally:  The default SMTP use today is "spam", abuse, and
spam-related messages (bogus bounces etc.).  Therefore the
default action in any case of doubt MUST be "reject a.s.a.p.".

Frank, I don't know how, or if, either of us is going to
persuade the other, but I'm operating under three assumptions
with this draft and will continue to do so unless the ADs or
some appropriately-chartered WG tells me otherwise.  Those
assumptions are:

(i) The goal of this revision effort is to clean up
    errors and bad text to the extent necessary to move
    2821bis forward to Draft Standard.  This is not a
    "revise SMTP" or "change mail philosophy" effort.

   This can be done while separating out best-practices issues.
(I'm pretty sure there's rough consensus that any major philophy
changes should be separate from 2821 updating.)

(ii) The ground rules for this effort are the same as
     those for DRUMS, i.e., clarification and consolidations
     of the base specifications and documentation of
     contemporary practice consistent with those
     specifications, not insertion of new features or ways of
     doing things.

   Contemporary practice already includes many anti-spam and
anti-abuse practices, with no hint that such practices will go
away anytime soon. IMHO, contemporary practice is diverse enough
to mitigate against trying to document it in the spec document.

Those two assumptions are obviously closely related to each
other. The third very nearly follows from the other two, but is
a statement about philosophy:

(iii) Whether via extensions or other add-ons, changes in
      operational practices, or changes in laws and consequent
      enforcement, we will get the spam and abuse situations
      under control.

   (Note John K _doesn't_ say "during our lifetime"...)

      When we do, we will still want a mail system that is
      optimized for the efficient and reliable delivery of
      email. Such a system tries to deliver messages and
      reliably report what cannot be delivered.

   My sentiments exactly!

   (We do currently have a problem reliably reporting failures.)

      It is designed around very high expectations that a
      legitimate user, even an anonymous one, sending
      interpersonal mail to a legitimate user or mailbox,
      will see that mail delivered, and delivered quickly.
      It does not look for excuses to discard messages because
      they do not conform to one rule or another.

   Current practices, alas, often do just that.

   While I do not wish to discuss them in this document; we
should be careful how deep we bury our heads in the sand...

      Changing the base SMTP specification in significant ways
      to accommodate the short-term battle against spam or other
      forms of abuse in ways that violate those assumptions is
      pathological because, on one hand, it gives us a damaged
      mail structure forever.

   Certainly, changing SMTP to (attempt to) match current anti-spam
practices is likely to lead to long-term damage.
      Conversely, if the hypothesis that we will get the present
      situation under control is false, SMTP modifications are not
      going to be sufficient: we will need a permission-based, or
      rigid-authority-based, mail system and SMTP will die
      regardless of what tuning-level changes are made to it.

   There may be a middle ground: try to forgive me for believing
that some of the features of current SMTP being exploited by spammers
and other abusers might actually be things we could aim at fixing.

   I choose to put my efforts into extensions to SMTP rather than
trying to guess at SMTP-NextGeneration. Thus, I will listen carefully
to any proposals to strengthen accountability (where such is desired
by both sender and receiver) or to improve opportunities for
cooperative efforts to track problems. And I remain particularly
interested in how to generate useful NDNs when reverse-paths seem
to have been forged.

   I will try to be well-behaved, not insisting that folks support
half-baked ideas. But I think we'd be unwise to stick too firmly
to principles which have been abandoned by a large majority of
actual SMTP servers.

John Leslie <john(_at_)jlc(_dot_)net>

<Prev in Thread] Current Thread [Next in Thread>