Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt

[Frank Ellermann <[e-mail]>]

John Leslie wrote:

> The IESG intent at the closing of MARID was that the various
> drafts be submitted by individuals for "Experimental" status.

I've never found out what the intent was of not discussing CSV
at all, and something like v=spf1 (spf2.0/mfrom) for only three
days.  After some time of being stunned I decided that it was
an experiment to prove that RfC 3710 (4.3) is incompatible with
RfC 2418 (4).  <shrug />

The damage is done, let's forget it and move on.  I also think
that e.g. MTAMARK is an excellent idea.  Couple this with say
SIQ, add draft-hutzler-spamops, 2476bis, okay, I'm dreaming :-)

> Misdirected bounces are a significant problem:

Indeed... :-(  And I have serious doubts about reporting them
as spam if the receiver didn't have a fair chance to reject
this crap (instead of bouncing).  If that somehow "encourages"
admins to delete mail, SMTP is in trouble.  That would be NOW.

> I have the impression that SPF intends to do more than this.

Sure, PASS + RHSBLs (black or white) make sense.  With a PASS
RfC 3834 works as expected (defining "oops, now I'm blocked"
as unexpected outcome).  Even C/R systems might start to work,
or let's say they are less dubious based on a PASS.

 [zone cut]
> I would recommend clarifying whether any such intent remains.

No.  I never understood what's so fatally wrong with q=ns, see
draft-newton-maawg-spf-considerations-00 (6.2) for a part of
the explanation.  The CSV trick (up to 6 queries removing the
labels left to right protecting the root servers) was a bit too
complex to be retrofitted into v=spf1 - we have no bit for an
include_subdomains=yes (old idea in an early SPF draft).

For some time I proposed to allow both ways (q=ns and left to
right, the latter with an op=nosub), but it was easier to just
drop the "zone cut" concept, because nobody had implemented it.

It was also an IESG [Discuss] => get rid of it before it bites.

> "... -all" should mean the sender _wants_ forwarding to break

That's not exactly true.  Forwarding in the sense of MUA to
MSA or smart host to mail out does of course not break (unless
somebody screws up), because SPF isn't checked there.

Forwarding in the sense of MX to scanner to MDA (or similar,
add UUCP if needed ;-) also doesn't break for the same reason.

As long as SPF is checked exactly once at the imaginary border
defined by the MX of the receiver nothing breaks.  This also
includes aliases behind the same border, and the 1123 5.3.6 (b)
style of mailing lists.

Obviously a backup MX forwarding to the primary MX needs to be
white listed, "check exactly once at your border" is a simple
rule.

Otherwise it's a case of forwarding to a third party.  With a
5.3.6 (b) scheme, SRS, etc. it still works, the only case that
"breaks" is 5.3.6 (a) if the next hop checks SPF.  And that's
behind the border of the original RCPT TO.

BTW, so far I've seen this once in a year.  It worked like a
delayed 551 "user not local" (the next hop rejected the mail,
and the 1123 5.3.6 (a) forwarder bounced it to me).

Comparing one good bounce with the 150,000 misdirected bounces
I'd say it's a deal - and I simply sent the mail again to the
forwarded-to address, this bounce was really "551-like".

Saying that the _sender wants forwarding to break_ is therefore
not correct.  Maybe the _receiver wanted forwarding to break_ :
after all he should know that he checks SPF at host B and uses
a 5.3.6 (a) forwarder host A _before_ B, that cannot work.  The
sender cannot know this, but the receiver should know it.

> Experience so far has proven that "... -all" is very
> problematic

That's not my "551-like" experience.

> My overall impression is that SPF probably strikes the wrong
> balance between ease of publishing vs. ease of checking

It's certainly not as simple as I'd like it to be, but when I
found SPF (the AOL experiment last year) it was almost ready,
and I needed "something like RMX yesterday".  SPF was the only
game in town at this moment, and that's still the case.

                             Bye, Frank