spf-discuss
[Top] [All Lists]

Re: Re: Drive Towards Consensus

2004-06-17 16:12:31


--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>


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