On Tue May 24 2005 13:05, Frank Ellermann wrote:
Bruce Lilly wrote:
[POSIX timestamp]
Would that be the one that fails to account for leap seconds?
Yes - better check it if this was no rhethorical question,
I'm not sure => if and only IIRC 24*60*60 seconds per day.
Not rhetorical; I've seen POSIX values suggested in another context.
The end result of that discussion was to do something more sensible,
viz. to use the same timestamp format already used in message
header fields, the RFC 2822 date-time. That's not tied to any specific
OS, and code to generate and parse it is readily available. And it
accomodates leap seconds.
The I-D tracker is the IESG's POV. It's not always exactly
the same as the author's POV, or the RfC editor's POV, and
they are free to change their opinion.
Recent experience with the IESG indicates that a change in intended
status (reasonably) entails the start of a new review.
I've no idea when they publish submitted errata.
Neither do I.
The 2069
error (PEBKAC or not) is older. How long do you wait for
some missing slashes in 2045, a year ?
Something like that since the initial report to the authors. Reported
confirmed to the RFC Editor late last year.
There was also a
discussion about something in 2821 here, not yet published.
Unlikely to be published anytime soon. In the absence of a current
WG, the document Editor declined to confirm an erratum. I understand
his POV, but it doesn't bode well for interoperability.
the term "source mailbox" is devoid of meaning.
It means "responsible sender": Those who send mail, can
also receive mail, at least for potential error messages,
or as you said:
Of course a non-null return path needs to be resolvable
-- for the purpose of *receiving* delivery notifications.
Attempting to tie that to IP addresses or other domain names and/or
attempting to overload semantics of "source" or "sender" are other
matters. Note also, as previously mentioned, there are legitimate
reasons for directing delivery notification messages to a mailbox
other than a personal mailbox for the sender, and it is primarily
for that reason that "source mailbox", "responsible sender", etc.
are inappropriate terms.
That's at the heart of the problem -- it attempts to define
a set which makes no sense; worse than that, it is harmful.
It does not _attempt_ to define this set, it only _allows_
to define this set.
But as the sender of mail, and the person affected, it doesn't
allow *ME* to do so. If -- in a fit of stupidity -- somebody at
the ISP where I *receive* mail were to do so, I would either be
forced to use a null return path (breaking the intended function
of delivery notifications, as noted by Markus), or I would drop
that ISP like a hot potato and find one with more sense.
That's a huge difference. You are not
forced to define anything at all.
I'm forced to deal with the consequences of an action over which
I have no control, and that is worse.
extrapolate that to an ISP with "more than 1 million
customer connections"
Try nslookup -q=txt gmx.de
I get:
gmx.de text = "v=spf1 ip4:213.165.64.0/23 -all"
Is that supposed to be relevant to the point, which is that publication
of SPF records affect *all* parties associated with mailboxes using a
domain name (not just the registrant), and -- particularly among large
groups (tens of thousands, millions) -- one size doesn't fit all? Can
you guarantee that no person who *receives* mail at a domain under
gmx.de will ever wish to *send* mail from a convention site kiosk, an
airport courtesy lounge, a restaurant or cafe, a public access point,
etc.?
I see no problem with STD 3 section 5.3.6 (a)
251 without the responsibility to handle later bounces.
Just forward and forget, it hits somebody else directly.
STD 3 section 5.3.6 doesn't mention 251 or "bounces" (anywhere), and
(a) says:
(a) Alias
To expand an alias, the recipient mailer simply
replaces the pseudo-mailbox address in the envelope
with each of the expanded addresses in turn; the rest
of the envelope and the message body are left
unchanged. The message is then delivered or
forwarded to each expanded address.
[251 response codes are mentioned only in sections 5.2.4 and 5.2.10; 5.2.4
specifically relates to SEND, SOML, and SAML commands, which are irrelevant
to our discussion, and 5.2.10 discusses an exception to the rule of basing
actions solely on response codes rather than text, which seems inapplicable
as well]
Return-Path: <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Received: from mr09.mrf.mail.rcn.net (EHLO mr09.mrf.mail.rcn.net)
(207.172.4.28)
by ms07.mrf.mail.rcn.net (MOS 3.5.6-GR FastPath queued)
with ESMTP id GKT45663;
Thu, 19 May 2005 14:37:59 -0400 (EDT)
Received: from mx23.mrf.mail.rcn.net (mx23.mrf.mail.rcn.net [207.172.4.102])
by mr09.mrf.mail.rcn.net (MOS 3.5.7-GR)
with ESMTP id CCC77732;
Thu, 19 May 2005 14:29:45 -0400 (EDT)
Received: from unknown (HELO mx23.mrf.mail.rcn.net) (10.255.5.102)
by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:44 -0400
Received: from gundel.de.clara.net (212.82.225.86)
by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:41 -0400
Received: from [62.80.58.103] (helo=xyzzy)
by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD)
id 1DYpzH-0005K5-W5
for blilly(_at_)erols(_dot_)com; Thu, 19 May 2005 20:43:16 +0200
Message-ID: <428CDA90(_dot_)3522(_at_)xyzzy(_dot_)claranet(_dot_)de>
Okay, somebody claiming to be nobody(_at_)xyzzy(_dot_)claranet(_dot_)de sent
a mail to blilly(_at_)erols(_dot_)com
`nslookup -q=mx erols.com` says mx.mail.rcn.net, the border
MTA is apparently mx23.mrf.mail.rcn.net. It talked with IP
212.82.225.86 saying HELO gundel.de.clara.net, no SPF policy,
result "none". It was MAIL FROM:<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
The draft under discussion states "At least the "MAIL FROM" identity
MUST be checked". HELO doesn't enter into this discussion which, as
originally noted, deals with one specific problem related to MAIL FROM
misuse by the SPF draft proposal.
xyzzy.claranet.de text = "v=spf1 redirect=claranet.de"
which appears to point to:
claranet.de text = "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"
212.82.225.86 is a perfect match for 212.82.225.0/23, result
"pass". Congratulations, it was no mail worm or spammer, it
was apparently me (modulo screwups at this ISP).
At various points in transport
No, you don't check SPF whereever you like it. SPF defines
the border of the sender, the only point where that makes any
sense at all is your border.
And this is specified (using "only" and "MUST") in which section(s) of
the draft under discussion? I also seem to be having trouble locating
the supposed definition of "border" in the draft -- I see 5 instances of
the word, all within 1/3 of a page from one another, none of which
provides anything remotely like a definition, much less a reliable
mechanism for determining where it lies.
I do see:
Typically, such checks are done
by a receiving MTA, but can be performed elsewhere in the mail
processing chain so long as the required information is available and
reliable. At least the "MAIL FROM" identity MUST be checked,
Any of the places corresponding to Received header field lines correspond
to "a receiving MTA", which is the typical case specified in the draft
(it does not involve the "elsewhere" hatchway).
You can't check it behind your
border, you check it at mx23.mrf.mail.rcn.net
Unless "xyzzy.claranet.de" is now a subsidiary of "rcn.net" or vice-versa,
that is *NOT* "the border of the sender". Nor is it *MY* border. And if
one does check at "the border of the sender", the client IP address is (as
noted earlier, but not quoted by you) 62.80.58.103, which doesn't match
the supposed sender SPF IP address ranges.