John Leslie wrote:
I prefer the usual style of 2119 keywords with a reference.
Anything else leaves the reader wondering why 2119 reference
wasn't used. (The document is quite hard enough to read
without adding challenges like this...)
Yes, and John K's proposal "read te DRUMS archive" is not very
attractive for me... ;-) Of course it's allowed to invent new
keywords, or "only" a new semantics for keywords also defined
in 2199...
...BUT when I read this part I didn't see that it's "new", it
sounded like what I think 2199 means. For ABNF details it's
clear that I have to check it letter by letter, e.g. the 2821
"at least one dot" rule depended on a single "1" in the syntax.
...BUT that I'm now also supposed to check the 2821bis-variant
of 2119-keywords is odd. It violates two of the "golden rules"
if there really is a difference: a "high astonishment factor"
instead of "build on the work of others" (= use 2119 keywords).
[numerical addresses]
I tend to agree: I think we can go to "MUST NOT" for any
numerical addressing except <address-literal>; and
<address-literal> deserves a SHOULD NOT.
With John's parallel comment maybe saying "MUST NOT" at this
place is confusing, and a pointer to A.6.4 is good enough:
| 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 (see A.6.4).
Forward references are ugly, but I want it clear that this
SHOULD NOT is about <address-literal>, not the old #-literals.
I do not mean to say that we can require much about the names
used in HELO: I merely mean that a HELO name should introduce
_some_ information (however slight) beyond the IP address we
already know.
You probably like the new <Explained-literal> for EHLO. I fear
we can't do more about it in 2821bis, and if servers refuse to
talk with EHLO-literal != IP they are on their own. Oops, nice
subtlety in the new syntax: No <address-literal> with HELO, if
that's intentional I like it. :-)
[proposed 2.3.8 text]
| 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.
I don't think this helps. Inevitably, the reader will stumble
on "transport service environment": better IMHO that this
term be introduced after a more familiar idea is stated.
Okay, you both didn't like it, so the idea isn't clear. What I
_wanted_ was to catch the difference between mail-originator
(or rather message-originator) and SMTP-originator.
If this article makes it to you I'm the message-originator. I
"posted" it on GMaNe as "news article". GMaNe pretends that
"mailing lists" are "moderated newsgroups", and the list
address is the "moderator". Therefore it "submits" the posted
article to the list using SMTP and its own reverse path (in
theory it could use other transport systems). The list has no
idea about these details, it somehow checks that GMaNe (2821)
or me (2822) are allowed to post, and then it redistributes the
mail to all active subscribers: Incl. GMaNe, that's how I see
it, because I'm no (active) subscriber. For the redistribution
the list uses its own reverse path, it's no "alias-exploder" -
(and GMaNe has a SPF FAIL policy, so the latter won't work).
So from your POV the SMTP-originator is the list, unless you
introduced your own tricks somewhere between you and the list.
Ignoring obscure 2822 manipulations of the header I'm still
the message-originator. Fortunately this is 2821bis and the
SMTP-list, therefore we can really ignore most 2822 issues.
And that's what I want to get clear in the 'tricky statement'
about "originating" system / SMTP originator / Internet -
it (apparently) conflates mail == SMTP == Internet, and IMHO
both equations would be plain wrong.
For one part it's a question of the definition, we could say
that "mails" are those messages transported by SMTP, anything
else (UUCP, news, or whatever) can be message/rfc822, but is
no "mail" as defined by 2821bis. _If_ that's the real idea of
the 'tricky statement', for the second part "Internet" I'm lost.
At the end of 2.3.8:
[[Note in draft/Placeholder: There has been a request to
expand this
[...]
gateways acting as SMTP originator
[...]
IMHO, this section would be a poor place to go into such
detail. Here we should limit ourselves to what a gateway _is_
(which probably needs a discussion of its own): not what a
gateway may or may not do.
One problem with gateways, there all kinds of them. And they
are a potential cause of trouble. E.g. if somebody builds a
nanas-to-this-list gateway, and I post in nanas, then I'm not
responsible for the trouble in SMTP-land, so in that case the
gateway should ("MUST") use its own reverse path - in fact it
should be closed for stupidity, but that's beside the point.
From your POV (SMTP-land) it's "Return-Path:<this list>" and
so you'd talk with the list mom to stop this flood. In the
case of an alias-exploder (bad idea) you'd talk with the admin
of the rogue gateway. But you shouldn't be forced to talk with
me, this weird nanas-gateway wasn't my idea, I can't fix it.
That's "my" concept of a reverse path, "whatever you do, make
sure that it doesn't hit innocent bystanders" (e.g. if forward
path and reverse path are different make sure that the latter
is willing to play along in the case of any trouble).
Nothing new, only the top priorities swapped: It used to be
"1 - if at all possible try to deliver" + "2 - cause no harm".
Today "2" is more importat than "1", because most mails are
unsolicited and more or less bogus.
[2.4 (minor nits)]
? In some commands and replies, arguments MUST follow the verb
| In some commands and replies, arguments follow the verb
(Frank would do well to make his intent clear _without_ the
reader needing to hunt down the text he's referencing.)
John Klensin's draft includes the "MUST": I don't understand
what Frank dislikes about it.
I don't like the MUST because this is no normative 2119-MUST,
some must, others don't, so what's the point of 2119-language ?
The details where arguments really MUST follow the verb are in
chapter 3 and 4. Maybe a matter of taste, but I want to see a
MUST (or MUST NOT) only where it's really necessary for reasons
stated in 2199. As I said, "minor nits", no big issue.
Please let's reserve "bounce" for "bounce messages" (NDNs),
i.e. the client. If an MDA creates a bounce after the MX
accepted the crap, then it's almost certainly net abuse.
We might be better to avoid the "bounce" term altogether.
It's an idea. The common understanding is apparently bounce =
NDN (incl. pseudo-NDNs like MAIL FROM:<mailer-daemon(_at_)example>).
In my experience, "bounce" is _often_ misunderstood.
Yes, I'd like to have it clear that "reject" is almost always
better than "accept and bounce later". Or "don't _accept_ the
responsibility if there's no serious chance for a success, you
are in trouble if the reverse path is bogus" (= default today).
IMHO we need to remove any obligation to generate NDNs to
addresses which are reasonably believed to be unrelated to
any author or sender of the email in question.
ACK, that would be a major step forward. But we must not kill
the reliability of "legit" SMTP while we're at it. The best
strategy is IMHO to stress what "accept responsbility" means,
and why not accepting this responsibility can be a good idea.
Bye, Frank