spf-discuss
[Top] [All Lists]

MAIL FROM address literals etc. (was: SPF v1 draft for review)

2004-10-13 05:50:00
Mark Lentczner wrote:

The treatment of "postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4]" as Fail with 
reason
"Malformed Domain" is consistent with how "bob(_at_)bobs-machine"
and "bob" would be treated.

Yes, that intention was clear.  And then a "malformed domain"
is fine even if that results in a rejection of the mail.  But
I'm less sure about MAIL FROM address literals.  Rejecting any
MAIL FROM:<postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4]> RCPT TO:<postmaster> 
could be
a problem with RFCI (maybe).  It's not exactly the same as
MAIL FROM:<bob(_at_)bobs-machine>.  In the case of @[1.2.3.4] I'd
prefer to use a dummy sender policy "v=spf1 ip4:1.2.3.4 ~all",
or a similar solution not resulting in a reject.

While these might be legal MAIL FROM values for 2821, they
aren't things that can be evaluated by SPF.

All FAILs including "malformed domain" can be used to reject
mail (2.4.3), and that's not completely irrelevant in contexts
like rfc-ignorant.org.  I could list some restrictions for this
case (e.g. it must be a public IP, it should not have a FQDN,
there must be a smtpd accepting mail for 
postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4]),
but in some cases it might be still legal.

Maybe you could argue "no reverse DNS => no mail", and as a
side effect MAIL 
FROM:<postmaster(_at_)4(_dot_)3(_dot_)2(_dot_)1(_dot_)in-addr(_dot_)arpa> is
okay, but that's a weird solution.  Especially if you want to
send a bounce to this construct, let alone IPv6 variants.

the SPF type MUST be used

I prefer to think of this is line as the requirement, and
the algorithmic description just a consequence of
implementing it.

Okay.  My strategy would be to avoid any RfC 2119 keywords if
they're not absolutely necessary.  If an implementation MUST
implement an algorithm correctly, but it MAY also implement
another algorithm as long as the effect is the same, then I'd
delete the whole paragraph... <gd&r>  Not really important.

 [common mistakes: "include:invalid"]
This seems to be just a repeat of the very last line of the
ASCII art table.  If seems very clear that a "None" result
generates "PermError".

It should be clear, but apparently it isn't for some users (?)

"PermError" is another case of "SHOULD reject" (2.4.7), that's
rather serious.  Meng found an application where this might be
exactly what the sender wants, but I'm not yet convinced.  But
as you said it's more a problem with FAQs and wizards:

 [common mistakes: "a:1.2.3.4"]
Such things aren't supported by the grammar as it is.  I'm
going to leave this one for the F.A.Q.s

I'm a fan of "near misses" in examples, some users won't read
the grammar because they never learned to read BNF.  Some users
even try to write code on this shaky ground (shudder).  I made
similar errors in the case of XHTML documents and XML.

o  = original domain, domain of <sender>
d  = <domain> of evaluated sender policy

The terms <sender> and <domain> are well defined in the
document and used consistently throughout.

ACK.  What I really wanted was probably another table with the
mnemonics for all macros.  At the moment it's not easy to find
this in the draft (but possible).  o = originator, h = helo,
t = timestamp, etc.  Not very important, but please note it as
"nice to have" for future drafts.

the added wording only adds doubt that these terms might mean
something different here than anywhere else they are used.

IIRC "o" is the only macro where this isn't obvious, you could
add it as "(mnemonic: originator)" in future drafts.

[ "/" ip6-cidr-length ]
Actually, this is right.

Okay, I didn't know that you can have both kinds of CIDRs in
one directive:

a/26          - just an ip4 cidr length
a//80         - just an ip6 cidr length
a/26//80      - both

Thanks, that's _now_ clear, and a candidate for appendix B ;-)

We're talking about a domain with both IPv4 and IPv6 IPs for
its mailers, and I forgot that this is possible.  The double
slash avoids all ambiguities.
                               Bye, Frank



<Prev in Thread] Current Thread [Next in Thread>