--Jonathan Gardner <jonagard(_at_)amazon(_dot_)com> wrote:
[example1]
Accreditation is irrelevant. example1.com's reputation or accreditation
is beyond the scope of MARID anyway. We are merely trying to establish
authority.
I totally agree that rate limits are done by the transmitting MTA. Rate
limits are also beyond the scope of MARID.
Agreed, on both.
[example2]
Rate limiting is beyond the scope of MARID. We are only trying to
establish authority.
If accreditation services want to monitor rates and such, so be it. But
that is beyond MARID.
Agreed, though it is possible to implement some sort of rate limiting
"behind the scenes" in a custom DNS server. I agree that doing so is still
beyond the scope of MARID.
> Example3.com:
example3.com publishes:
"v=spf1 mx redirect=%{d}._customer.maridRus.com"
on example3.com._customer.maridRus.com, we have:
for 0.1% of the time:
"v=spf1 exists:CL.%{i}.FR.%{s}.HE.%{h}.null.%{d} ?all"
For the remaining time:
"v=spf1 ?all"
No, you can't change records willy-nilly in DNS. The SPF records are
practically etched in stone, and shouldn't be changed rapidly.
Actually, some appliances such as 3DNS by f5 do this with good results. I
have used 3DNS to load balance between multiple data centers, where each
data center has a different IP for the web server. This sounds like it
would be similar.
Granted, I would personally not use it for this purpose, but you could. I
would simply add the exists: clause every time, gather all the data and
summarize it myself. But, there are some cases where people might want to
do this, especially if this exists: clause causes weird stuff to be cached
by receivers.
(Somewhere we should make some notes about how to use exists: for reporting
like this, and recommend to people doing this that the A records that come
back (as well as the negative responses) get a very short TTL so they don't
choke out other less-dynamic data in the cache)
Using exists: is a good way to get tracking of who is sending from where,
but it's also a good way to get whatever weird behavior you want... you
just have to supply a customized DNS server. Let's not forget the power of
exists: to do certain kinds of extensibility :)
> Example4.com
> Example4.com is an esp bounce handling domain. This domain appears
> only in MAIL-FROM and never in SUBMITTER or the 2822 from address.
"v=spf1 +all 2822.from=never"
Now, this isn't a really good solution in either SPF-classic nor
SPF-ID, but the syntax is there.
I thought we weren't doing 2822 record checking. Amazon.com is sending
emails 2821 "MAIL FROM
(_dot_)(_dot_)(_dot_)(_at_)bounces(_dot_)amazon(_dot_)com", but we never put that in
the 2822 record.
SPF Classic is for MAIL FROM, but the proposed Sender ID can be used in
2822 space (using PRA).
It's important to note that *most* of the time, the 2821 and 2822 policies
*for the same domain* will be the same, or it will be easy to make the TXT
record be a superset of both. There will be very very few cases where
people will say "I will use this domain in MAIL FROM but not in From:" and
have people really care -- if the IPs listed in the record are trusted,
they should be trusted to use the name properly :)
So, if we move forward intending to be able to use SPF mechanisms for both
2821 and 2822 (which I think it would be GREAT for in both cases) we will
probably put a hook in that says something like what Wayne wrote, but I
would downplay this. Very few senders will ever need it. For those cases
where there might be a conflict, they will find it easier to just use two
domains (like pobox.com and bounces.pobox.com)
In general, it is possible to use modifiers like blahblah=mechanism:value -
even though it contains a mechanism and a colon, it should still be treated
as a modifier only. Someone who understands blahblah can execute it if he
wants...
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>