Margaret and SPF-discuss:
As I'm sure a few people know, the IETF MARID co-chairs asked for
examples of situations that could not be express in SPF syntax. These
examples will be collected over the next several days, but ALL REPLIES
are to wait until next Monday.
Margaret posted the following list of examples, and I'm replying to
SPF-discuss so that everyone can see my reply. I am also sending this
email to Margaret so that she knows where to find further discussion on
her examples. It probably would be best not to mailbomb Margaret with
every reply sent to the list, I'm sure she gets enough email as is.
Many of the "answers" I propose are not strict translations of the
situations into SPF syntax, but rather, ways that I think accomplish
the same thing, often in (IMHO) better ways. One of the strengths of
the SPF community is that we have a lot of sharp folks and different
people come up with different and, often, more appropriate solutions.
So, here is my reply:
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"
The volume sent by the two email provides is irrelevant, because that
is not something that email receivers need to, nor should care about.
Rate limiting must be done via the MTAs from those other companies.
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.
If there is no accreditation, how will receivers know that rate limits
are enforced? What value to a receiver is it to see a claim about
example2.com being made *by* example2.com being able to send a limited
number of emails?
If this information is going to be of use to anyone at all, it needs to
come from personalemail.com and esp.com. So, you might 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.
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.
I don't understand what you mean by "100% of the abuse complaints".
Are you talking about things like registering at abuse.net and
spamcop.net? What is the matter with using the RP DNS record? (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, what are you
trying to accomplish? Are you trying to track where people are
sending email claiming to be from example3.com? If so, wouldn't
collecting all data for 1/1000 as long do just as much? maridRus.com
could also publish logging SPF records for short periods of time using
short TTLs and sample at different times of the day.
So, anyway, something like the following might solve the problem:
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"
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