I've loaded the SPF rfc into my shiny new RFCwiki.
http://zarquon.advenge.com/RFCwiki/view?doc=AG
I have given the listed authors full access list editing privs,
log in with your e-mail address as listed in the document. Reload the
wiki after logging in -- I'll fix the "back to" button when I can.
RAPNAP is a centralized challenge-server system.
The user and admin interfaces described at http://pay2send.com/rapnap/
have been working for over a year
Return Address, Peer Network Address Pair. To fully communicate
a domains valid RAPNAP set, which is a list of all the IP addresses that
all the legit senders use, over SPF, an extension to the
macro definitions to provide a letter for the envelope sender. The
domain of the envelope sender is implied, with SPF, because we're
adding records to that domain, (unlike with a central RAPNAP
service as envisioned
http://pay2send.com/OMX_deprecated_version0.txt
http://msgs.securepoint.com/cgi-bin/get/djbdns-0306/11.html
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06604.html
for instance, which needs the return address domain because its
centralized.
the l macro is right at the top of the list. So I will be fully able
to expand the RAPNAP database currently collected and distributed
strictly as a webservice into a DNS service and publicize a SPF
invocation that will mean, we're all registered with the tipjar RAPNAP
server, check it. And that SPF invocation will be, let's see...
v=spf1
-exists:%{s}.%{ir}.bad.rapnap.advenge.com
+exists:%{s}.%{ir}.good.rapnap.advenge.com
~all exp=explain.rapnap.advenge.com
The intended result is, relays
that have been specifically identified as joe-jobbing -- or just no
longer used -- are identified and dismissed with the "bad" list, then
relays that are not listed in the MX set. Does this scheme really save
any effort over listing address records for all the good ones? Unlisted
relays generate "softfail" which is expected to create a temporary
delivery failure until we get a reply to a probe e-mail which is
triggered by appearance of a new %s,%i pair, unless the %s in question
has locked their record.
The RAPNAP web service currently takes subject line and addressee fields
so it can construct e-mails that appear to be in response to what was
sent. Neither of those fields is available until the data phase of the
SMTP transaction so it makes sense to leave them out, but they are very
useful for constructing challenges and therefore it would be good to add
them to the list of expandable macros. Without those macros -- which
would make the exists: names really long. Lets say %u is subject and
%e is addressee (my system only accepts one recipient at a time from
people it doesn't know already)
+exists:%{U}.t.%{E}.f.%{S}.%{ir}.good.rapnap.advenge.com
might get pretty long. The server gets to throw out everything to the
left of the .f. except when asking for a new challenge to be sent if
appropriate:
v=spf1
-exists:%{s}.%{ir}.bad.rapnap.advenge.com
+exists:%{s}.%{ir}.good.rapnap.advenge.com
+exists:%{U}.t.%{E}.f.%{S}.%{ir}.good.rapnap.advenge.com
~all exp=explain.rapnap.advenge.com
accredit=%{s}.accredit.advenge.com
The last line will turn into the worlds fastest credit check.
David Nicol
--
david nicol
"Accreditation providers can make up any protocol they like
as long as they can convince receivers to use it." -- Meng Meng Wong