Bruce Lilly wrote:
154 people. Out of approx. 10 billion. Unimpressive.
If it's more than USEFOR + LTRU + CLEAR + MASS + ASRG
I'd be mildly impressed. Completely beside the point,
better check out who wrote this:
http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00329e.html
MAIL FROM remains unchanged during transport
After so much talking about 1123 5.3.6(a) I'm certain
that you also know (b). You've reviewed email-arch-04
here on this list less than six weeks ago, it explains
"mediator", probably a better term than "1123 5.3.6".
attempts to assign a relationship between domain names
and IP addresses for sending email
s/attempts/allows/
[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.
It has been asserted that some hosts lack the capability
to determine time (e.g. see the RFC 2476 successor draft)
My own box does not really know its time zone, for some
hours at the begin and end of DST it's seriously confused.
Until I fix it. With funny effects like an online idle
timeout deciding to cut the connection.
An RfC 3339 timestamp would have the same problem here.
Rather irrelevant for the draft, it's only an optional
timestamp in an optional explanation sent with an SMTP
reject message for result FAIL. At the moment it says:
| if there are syntax errors in the explanation string,
| then proceed as if no exp modifier was given.
Adding "or the client cannot determine the timestamp for
a specified %{t} macro (see 8.1)" before "then" would be
no problem.
When one asks for review of a draft intended for RFC
publication, it is at least a common courtesy to clearly
and unambiguously indicate the intended status.
This thread started with Wayne's article:
| My intention is that after a two week review, I will make
| a "final" revised draft and ask the IESG to consider it
| for a Proposed Standard status.
I've forwarded the question about how this can be done with
xml2rfc to the xml2rfc list. You discussed this issue here
with Ned. And the IANA mail header registration form said
"Status: standard", let's move on.
the I-D tracker says one thing
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.
If you mean the current BCP 78 (RFC 3978), there are no
errata published as of this morning
I've no idea when they publish submitted errata. The 2069
error (PEBKAC or not) is older. How long do you wait for
some missing slashes in 2045, a year ? There was also a
discussion about something in 2821 here, not yet published.
Like you I simply quoted STD 10.
I cited specific cases related to reality
You quoted 821, and when I did the same, you said that it's
obsolete metioning 2821. Then I quoted 2821, and you said
that 2821 has known issues:
[...]
it has been taken into account in the specification (RFC
2821) which obsoletes 821.
[...]
There are several problems in 2821; as already noted, a
mailbox receives mail, so the term "source mailbox" is
devoid of meaning. RFCs aren't always flawless.
[...]
if you really think that source routes are in current use,
you are deluded.
And I wouldn't need SPF. That's the point, if STD 10 would
(still) work as designed something like RMX or SPF would be
completely unnecessary:
Bounces would take the reverse path, hop by hop. Therefore
forwarders would make sure not to forward undeliverable
crap from unknown stragers, because they'd later be forced
to deal with the bounces.
Therefore like 551 "user ot local" existed, because a 251
accepted responsibility for later potential bounces. And
that's the precise reason why STD 10 had it right, at least
in theory, and 1123 broke it - unintentionally but still.
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.
[set of mailout IPs for mail users @ FQDN]
that's the idea of RMX/SPF, it allows to define this set.
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. That's a huge difference. You are not
forced to define anything at all. If you want to define it,
you have great flexibility. If there's exactly one zombie
forging your address and you get the bouces, you can define
something like "v=spf1 -ip4:<zombie.cidr> ?all".
Just make sure that you're not sending from the same CIDR.
You will immediately get less bounces. And if the zombie
is controlled by a spammer (not only a mail worm) he might
decide that abusing your address is no fun anymore, because
receivers checking SPF won't accept mails with your address
from <zombie.cidr>. Even spammers understand this, sooner
or later, "my" spammer(s) needed about four months.
extrapolate that to an ISP with "more than 1 million
customer connections"
Try nslookup -q=txt gmx.de
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.
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>
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. You can't check it behind your
border, you check it at mx23.mrf.mail.rcn.net
Working as designed, bye, Frank