Bruce Lilly wrote:
I said "apparently"
Yes, and I explained why that appearance is wrong.
I'm giggling. Was that the intended effect?
<http://purl.net/xyzzy/home/test/spf-council.htm>
<http://www.OpenSPF.org/cgi-bin/openspf_pledge.cgi>
the IETF and IAB generally don't like specifying
multiple incompatible ways to do the same thing
The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
do very different things, SPF covers some older ideas.
If "the IETF" has a problem with stating the common
practice in SPF, then "the IETF" would not have closed
MARID only three days after a potential successor was
proposed, don't you think ? JFTR, I was an RMX friend
back in 2003, but the deployed mechanism is v=spf1 -
don't think that I like all of its baroque details,
ok.: | standard dotted-quad format.
At minimum, needs a normative reference.
(to Wayne: please fix this in -02, e.g. <dotnum> in STD 10)
ok.: | time() function in most standards-compliant libraries.
Refers to POSIX, an external standard. Raises questions
about implementations.
It is in an example, ..."the same value as returned by the"...
I quoted only the part of the four lines where I found the
string "standard" in the draft. Yes, it raises some questions,
of course I wanted RfC 3339 in MARID. But it was far too late
and not that important. I'm too lazy to find RfCs using this
kind of POSIX-timestamps, I know that I've seen at least one.
Is the specification intended to exclude such hosts from
using the specification?
No. With my REXX I'd use something like the following:
/**/ say 86400*( date('b') - 719162 ) + time('s')
Probably off by one day and it needs fixing to get UTC, but
let's say that it's not impossible to solve this problem on
any host with date and time. It's only used in an _optional_
explanation string, not very critical.
(to Wayne: please remove '"exp" counted' in 10.1 - throwing
a PermError after the result is clear is rubbish)
ok.: mail header registration form | Status: standard
Not OK for an Experimental or Informational RFC
Now if the I-D would intend to be one of these, then it would
of course use the corresponding status. But the form doesn't
have any "Status: TBD". This stuff could be updated in the
48 hours if necessary. Okay, you propose "historic", I doubt
that Wayne will follow your proposal.
something which is obsolete or harmful.
Which isn't the case after we have found that the conspiracy to
exclude non-POSIX hosts from SMTP failed miserably.
[boilerplate]
IESG/IAOC/IPR WG's problem.
Okay, let them have fun. My BCP 78 erratum is available at the
RfC editor (or that's what I hope).
You're:
a) confusing *typical* cases
Like you I simply quoted STD 10. If that confuses you it's sad,
I think it's crystal clear.
b) ignoring the fact that, as explained in some detail, the
MAIL FROM argument is passed unchanged from one MTA relay
to another during transport
Not in STD 10. Are you now starting with RfC 1123 5.3.6 (a),
or are you still talking about STD 10 ?
| In any case, the SMTP adds its own identifier to the
| reverse-path.
quoting a twenty-year old document
Yes, that's what you did. If you don't like it just don't.
obsoleted by a newer document (RFC 2821) that (presumably
intentionally) does not include many of the phrases which
you have quoted.
We can also discuss RfC 2821 if you like. You quoted STD 10.
BTW, RfC 2821 is a proposed standard published April 2001.
Wasn't it you who said that proposed standards should be moved
to either "draft" or "historic" after at most two years ?
| Such a transaction consists of a series of commands to
| specify the originator and destination of the mail
..............^^^^^^^^^^
..........................vvvvvv
| Commands specifying the sender or recipients may include
| server-permitted SMTP service extension requests
....................vvvvvvvvvvvvvvvvvv
| It consists of an originator address (to which error reports
| should be directed)
.
That's not 20 years old, that's RfC 2821, if you like it more.
No mention of what happens if EHLO/HELO is a literal or
unqualified or NXDOMAIN *and* MAIL FROM is null
| This document defines a protocol by which domain owners may
| authorize hosts to use their domain name in the "MAIL FROM"
| or "HELO" identity.
It's about domain names, not domain literals, NXDOMAIN, etc.
| When the reverse-path is null, this document defines the
| "MAIL FROM" identity to be the mailbox composed of the
| localpart "postmaster" and the "HELO" identity (which may
| or may not have been checked separately before).
| Note that requirements for the domain presented in the EHLO
| or HELO command are not always clear to the sending party,
| and SPF clients must be prepared for the "HELO" identity to
| be malformed or an IP address literal. At the time of this
| writing, many legitimate e-mails are delivered with invalid
| HELO domains.
I could quote more until we finally reach the point where it's
clear that "no sender policy => result none" in all cases, even
some pathological cases.
Receipt (but not *sending*) of mail is tied to a domain name
by DNS MX RRs.
Check out the parts about "domain", "HELO", and "MAIl FROM" in
RfC 2821 again, they MUST be resolvable (MX. A, CNAME), and we
already discussed MAIL FROM:<> (see above).
In particular, no fixed set of IP addresses is associated
with the sending of such mail;
Yes, that's the idea of RMX/SPF, it allows to define this set.
With great flexibility like say "everything but this CIDR".
If that's not what you want for erols.com just don't define it.
Domain owners
Bzzt. Fatal flaws. see above.
If you don't like RfC 2821 chapter 3.6 that's your choice, but
no fatal flaw. The only fatal flaw is RfC 1123 5.3.6 (a), and
SPF allows to fix it for those who wish to fix it. Quite a lot
of users wish this. Recommended reading:
<http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00329e.html>
There is no "protection"
Of course. We're talking about TeraBytes and Billions of USD,
not peanuts. My personal damage was 150,000 bounces and other
backscatter before "my" spammer got the SPF FAIL idea, see also
<http://mid.gmane.org/42846DD2(_dot_)42D6(_at_)xyzzy(_dot_)claranet(_dot_)de>
Bye, Frank