Bruce Lilly wrote:
Scott H. wants us to use the new 2234bis in the References.
A normative reference would hold up publication, as the 2234
successor isn't yet a published RFC.
<http://mid.gmane.org/046F43A8D79C794FA4733814869CDF0749C9AF(_at_)dul1wnexmb01(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
It's not that I necessarily agree, but it's also not an issue
where I'd risk a debate with an AD if I care about the draft.
how should we reference terms defined elsewhere ?
a) use a term defined elsewhere, including the source as a
normative reference.
Is this also possible for something like "token", where even
the source RfC 2045 offers no proper syntax, let alone ABNF ?
Serious question, I was surprised to find this trick in 3834,
where I guess that it must have passed your review (and we're
still discussing related 2045-issues in USEFOR).
b) write the necessary ABNF. It's not rocket science.
For terms redefined by RfC 2231 I'd prefer rocket science ;->
Okay, no problem for Murray, he uses "token", not "parameter".
see the specific references to RFC 1958
That's an FYI, and it doesn't talk about "border MTA" issues.
all one can say about non-local content is that it's not
local '"not-ours"'.
If the domain owner of an address used in "not-ours" makes a
statement which MTAs he uses when sending mail to "strangers"
from his POV, then you can check this at your "border MTA"
and note the result of this check.
There's nothing wrong with this idea. BTW, nothing forces you
to use it if you don't like it for whatever reason. What you
like or not is strictly your business, but don't confuse it
with the "Internet Architecture". Maybe you need another
choice in your review-form: [X] I really don't like this idea
Ditto for the domain part of reverse paths.
The discussed draft nowhere says that the domain part of the
reverse path must / should have an IP, all it needs is either
a published (quote) "authentication policy of some kind" or no
such policy.
IMHO the phrase (quote) "sending domain" should be explained,
but that's not related to your review.
The last MTA used on the "not ours" side has an IP.
So what? "it came from somewhere". No unsigned content from
there (in particular, any plaintext assertions of prior
authentication) is trustworthy.
I don't disagree with your last statement. But I disagree
with your second statement, the "border MTA" (MX) is in the
position to identify a "not-ours" SMTP client, and this beast
has an IP, it says HELO FQDN1, and MAIL FROM:<local(_at_)FQDN2> or
MAIL FROM:<> among other things.
So if the owner of FQDN1 or FQDN2 defined the set of IPs used
by his MTAs when talking to the MX of a "stranger" (receiver),
then the receiver can check this at his "border MTA". Works
like a charm, if you get details like "not ours" and "border"
right. Now here's "no rocket science".
The draft proposes *deletion* of message header content
Oops, yes, (quote) "for security reasons". I had the "MAY
appear more than once" in mind. The only case I know where
a header field could be replaced is the Return-Path. That's
at the MDA, not in transit. And of course gateways might do
wild and wonderful things, but the discussed draft is about
a "border MTA", not gateways.
Mere drafts (e.g. "2234bis") are less desirable where there
is a suitable stable reference.
It's approved and in the in-queue. When are these famous 48
hours in this case, could it still be changed ? And Paul's
taobis I-D is simply nice.
Bye, Frank