In <50B2A36E-C00B-11D8-999B-000A95BC6A7E(_at_)margaretolson(_dot_)com> Margaret
Olson <margaret(_at_)margaretolson(_dot_)com> writes:
Here's are my first few examples:
Example1.com:
example1.com uses two providers: esp.com and personalmail.com .
Mail originating from personalmail.com is always conversational
(corporate individual mailboxes) and rate limited to 100 messages a
day by personalmail.com
Mail authored by example1.com originating from esp.com is rate limited
to 4,000 messages a month by esp.com. This mail is bulk mail.
example1.com is a small b to b service business, as accredited by
accreditors.com
Note: esp.com and personalmail.com set rate limits on a per customer
basis; these limits are functions of the customer, not functions of
the service that apply in an undifferentiated manner to all
customers. I am taking it as given that esp.com and personalmail.com
can write code to do lookups to check the veracity of their customer's
statements on the MARID record.
With SPFv1, this would be expressed as:
"v=spf1 include:esp.com include:personalmail.com -all
accred=%{d}.accreditors.com"
Rate limiting must be done via the MTAs from those other companies and
so that is where such information should be obtained. Otherwise, such
information is not trustworth.
So, you could have an SPF record that says:
"v=spf1 include:esp.com include:personalmail.com -all
rate=%{d}._rates.esp.com rate=%{d}._r.personalmail.com"
The receiver could then do a DNS lookup on example2.com.rates.esp.com,
and parse the TXT record, or use information from an A record or
something.
Example2.com:
Example2.com is a new customer at both personalmail.com and
esp.com. They have no accreditation or reputation, but each service
rate limits them to 100 messages a day and 400 messages a month, with
a total address count of 100. In other words, they can not correspond
with more than 100 different recipients over the period of a month on
either service.
Receivers side services can sum up the rate limits to calculate the
total number of recipients and messages that can emanate from
example2.com and decide whether it exceeds their policies on
authenticated but unaccredited senders.
See above for example1.com. I think it addresses this issue.
Example3.com:
Example3.com has limited internal controls and has decided to
outsource the whole record management and sending policy enforcement
problem to maridRus.com. They know they send outbound mail through
their inbound servers, but other than that they don't know how they
send.
maridrus.com starts by publishing a record referencing the mx
records. They need two kinds of feedback; abuse complaints, of which
they want 100%, and channels not listed in the example.com records, of
which they want 1 in 1,000 messages.
Abuse complaints is a hard subject. Many people do not want to send
abuse complaints to just anyone because spammers will listwash and/or
mark your email address as being live.
Right now, you have things like registering at abuse.net and
spamcop.net. There is also the RP DNS record that can be used. (RP is
the "Responsible Person" for the domain, see RFC1183 published in
1990.) Yes, you could also add a "rp=<email address>" modifier to the
SPF record, but I'm not sure if that is a good idea.
As far as getting information on 0.1% of the messages, I'm not sure I
see that as being much more useful than tracking 100% of the
messages. If you send X million emails, you are likely to get some
fraction of that X million DNS lookups anyway. Using an SPF exists:
tracking mechanism, you can efficiently track 100% of the invalid
messages.
You can use SPF right now to do sampling with records such as:
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"
This can be done with a very simple script, right now, with SPF
without any changes at all. You don't have to depend on the receiving
side SPF implementation understanding and obeying a new extension.
Depending on receiving systems will create a huge sampling bias. You
can fine tune things so that the tracking SPF record is deployed more
at night than during the day because the spam volume tends to stay
much more constant, but your server load is lower. You can deploy the
tracking SPF record right when you know you are sending a burst of
email.
You can do all sorts of stuff that is completely under the domain
owner's control and you can do it today. It would take me about 15
minutes to create and test a script to do this on my name server.
If you want to get fancier, you can hack up a name server to give out
the tracking SPF record one out of 1000 times it is requested. You
could decide by the domain requesting the SPF record what kind of
tracking you want done and have the name server respond accordingly.
Could you imagine the email policy description that would do something
like "send me information about invalid domain name usage, but only
around 08:00 UTC on the first monday of each month, and only if your
from domains x, y, or z, or in *.co.uk, but not ebay.co.uk". You can
do this today with SPF and a little creativity with your name server.
You will almost certainly never be able to do this if you try adding
extensions, even if you use XML.
Basically, I'm saying that the right place to evaluate these decisions
is at the ESP, rather than forcing/depending on all the receivers in
the world to do the decision making for you.
Over time, example.com and maridRus.com conclude that esp1.com and
esp2.com, in use by Departments A and B respectively, are authorized
vendors, and that they don't need to duplicate complaint
monitoring. They update the record such that complaints generated on
mail on the esp1 or esp2 channel are handled by the esps, and not
copied to maridRus.com.
Ok, so on example3.com._customer.maridRus.com, we change to:
"v=spf1 include:esp1.com include:esp2.com ?all"
As far as the abuse reports go, I think it is an incredibly bad idea
to send email to some arbitrary email address based on information
published in a possibly mallicious DNS record. That is one reason
that the RP DNS record has never found favor. Moreover, many people
do not want to send abuse reports directly to people who may well be
spammers or phishers.
The only real solution to abuse complaints are register with
spamcop.net, abuse.net and/or send email to
abuse(_at_)example3(_dot_)com(_dot_) If
example3.com doesn't want to deal with abuse complaints, it can
forward those on to someone else.
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.
Example5.com:
[This is included because I think that over time it will be useful to
everyone to have receiving as well as sending policies published, and
having another syntax for that side of the policy equation doesn't
make much sense to me]
Example5.com publishes their acceptance criteria as well their sending
policies. They accept mail from authenticated but unaccredited senders
who do not send more than 100 messages a day or 400 messages a
month. Otherwise, they accept accreditations from accreditors.com
(which presumably has pass-through arrangements with some number of
other accreditors). example5.com requires confirmed opt in from
everyone except senders accredited as financial institutions by
verythoroughandexpensiveaccreditations.com. For financial institutions
they require only prior business relationship, as defined by
verythoroughandexpensiveaccreditations.com
This is used by esp.com to decide whether or not to send based on the
characteristics of each of their customers, and to report back to
their customers on what they need to do to get their mail delivered.
Example5.com publishes
"v=spf1 .... incoming-policy=http://www.%d/incoming-policy.xml";
I don't see how your paragraph above leverages much, if anything, of
the SPF semantics, and it won't fit into a DNS lookup.
My real concern with SPF is the strong suspicion there is a lot we
haven't thought of yet.
I'm sure you are right. I don't see anything that causes a need for
XML though.
-wayne