Here is the RFC information for the acceptance of "domain literals"
(postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4], or any other
address(_at_)[1(_dot_)2(_dot_)3(_dot_)4]).
"Mailservers are technically required by RFC1123 5.2.17, to accept mail to
domain literals, for any of their assigned IP addresses. Not accepting
domain literals can make it more difficult to test a mailserver, and can
prevent that mailserver from receiving E-mail from people reporting problems
with your mailserver. However, it is unlikely that any problems will occur
if the domain literals are not accepted."
In deference to what the RFC states about the non-acceptance of domain
literals not causing problems with the acceptance of mail, the technique of
testing to see if a mail server actually exists, by attempting to validate
the postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4] e-mail address, is one form of
spam prevention that
is currently in use by some ISPs. (everyone is desperately attempting to
find a way to curtail the vast quantity of spam they receive!)
If the receiving e-mail server finds the sending e-mail server actually
exists during an attempt to send a message to
postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4], then the
message that was accepted for delivery is actually processed and delivered.
If the originating server does not respond to a request to send a message to
postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4], then the previously received
message is discarded.
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Frank
Ellermann
Sent: Wednesday, October 13, 2004 07:50
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] MAIL FROM address literals etc. (was: SPF v1
draft for review)
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
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com