On Tue May 10 2005 04:50, Frank Ellermann wrote:
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.
"Pay the AD now or pay the RFC Editor later". The RFC Editor will
hold up publication as an RFC until all normative references are
published. Expect a change in policy or delays in publication of
documents with ABNF. Note that there are some serious problems
with the ABNF draft (admittedly also in 2234):
http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html
Further note that the ID-Checklist specifies a normative reference
to 2234, not an informative reference and not a reference to some
other document.
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 ?
RFC 2045:
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
That's EBNF, so change ":=" to "=", "SPACE" to "SP", etc., fix
the missing "/" at the end of the second line of the tspecials
rule (erratum submitted and approved, but not yet published).
Also, current recommended practice is to specify the set of
permitted characters rather than an exclusion list.
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).
3834 isn't a critical issue; "token" is used in extensions, not
a fundamental part of the syntax. 3834 does refer to 2045 and
does not attempt to redefine "token" as an empty rule.
b) write the necessary ABNF. It's not rocket science.
For terms redefined by RfC 2231 I'd prefer rocket science ;->
It's been done.
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.
Informational RFC written by the IAB, not FYI. It addresses the
end-to-end issue.
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.
No, and this is one of the fundamental flaws with many anti-spam
schemes. Pay attention: the only domain associated with sending
SMTP mail is that which may be specified in HELO/EHLO, when a
domain literal is not used. The first problem with that is that
MUAs are also [E]SMTP clients, and many MUAs do not have the
ability to set the name proffered during SMTP sessions. The more
serious problem is that your "domain owner ... makes a statement
which MTAs he uses" amounts to a circular argument; the MTA
identification *is* the domain used in HELO/EHLO. Unless of course
you try to tie that to IP addresses, which doesn't work because of
DHCP, NAT, multi-homed hosts, and IP-less and/or domain-parked
domain names.
There's nothing wrong with this idea.
There's plenty wrong with it; it presumes a specific model that
simply doesn't apply in many cases.
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".
The Internet Architecture applies to the end-to-end issues.
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.
There is absolutely no reason to attempt any sort of "authentication"
of a reverse path domain; that has nothing to do with the sender per
se, it is (and always has been) a path for delivery-related
notification messages (RFCs 788, 821, 2821). Moreover, that reverse
path can be null, even though RFC 2821 fails to provide for that case
in its ABNF.
IMHO the phrase (quote) "sending domain" should be explained,
but that's not related to your review.
As noted, the draft needs a great deal of work before it can be
reviewed thoroughly.
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, for example it has an IP address of 123.45.67.89 and it responds
to the greeting with
HELO [123.45.67.89]
Perfectly legal and consistent with RFCs 821, 2821. So what?
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),
Sorry,
1) you don't have any "FQDN1"
2) there exists no Standards Track mechanism for "defined the
set of IPs used by his MTAs". Not even an Experimental RFC
AFAIK.
3) IPs change, due to DHCP among other reasons
4) as noted above, the name proffered in HELO/EHLO is often
outside of the control of the sender -- have you ever tried
to change what your "Mozilla 3.0" uses?
then the receiver can check this at his "border MTA".
Sorry, there are serious problems with the presumptions; the receiver
has nothing reliable to check, and no Standards Track mechanism with
which to do so.
Works
like a charm,
Unless you happen to be a mobile user with an MUA that insists on
using some specific string, connected to a network that blocks
outbound port 25 except to the network operator's MTA, the name
proffered by the MUA happens to resemble a domain name, and the
non-standard records maintained by the corresponding domain name
holder don't happen to include DHCP-assigned IP addresses doled
out by the mobile network you happen to be connected to. This is
another fundamental flaw in many similar anti-spam schemes; they
conflate the domain name which is associated with a mailbox (for
receipt of mail) with the process of sending mail. Pay attention
again: the domain name associated with the mailbox(es) where I
receive mail has nothing whatsoever to do with IP addresses from
which I send mail.
if you get details like "not ours" and "border"
right. Now here's "no rocket science".
Agreed "no rocket science", but for reasons other than you think.
"Rocket science" implies "science", whereas "get details ... right"
apparently involves voodoo like conflating sending and receipt of
messages and the pretension that NAT, DHCP, port blocking, domain
parks, non-configurable MUAs, and multi-homed hosts don't exist.
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.
And the point is that if it's not about gateways and not about
final delivery (MDAs) then modification of content other than
adding Received fields is ausschließlich verboten. [and adding
trace fields to the message content rather than to a separate
wrapper is a poor design choice that we've been suffering with
for more than two decades]
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 ?
48 hours is a minimum author's review period, after the RFC Editor
has edited the RFC. It has been known to take months. In this
case, let's hope there are changes, otherwise there will be a
round of repeated comments, suggested errata, probably a six-month
wait, and a likely reset to Proposed. So, yes, it can still be
changed, and is therefore not itself stable, and lacking an assigned
number has no stable reference.