-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 16 June 2004 09:59 pm, wayne wrote:
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"
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.
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.
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.
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"
No, you can't change records willy-nilly in DNS. The SPF records are
practically etched in stone, and shouldn't be changed rapidly.
If example3.com doesn't know how they are sending email, they have some
serious problems. That's like a company that doesn't know how their
invoices are being sent out. "Sometimes we put it in our mailbox, but other
times we just throw it out the window or give it to the homeless bum on our
doorstep." They'd better figure it out quick, or they will lose their
reputation.
If these guys have an ISP, they are using the ISP's mailing services. The
ISP will help them publish the right records. Heck, the ISP is providing
their DNS and web space as well, so the ISP will probably publish their SPF
records without them even knowing it.
As far as getting reports on mail abuse and such, that is beyond MARID. We
are only trying to establish authority. However, using the exists specifier
with an appropriate DNS server, it is quite possible to get a good sense of
what is happening.
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.
Complaints and reports of abuse are beyond the MARID charter. We are only
worried about authorization.
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.
If we establish that only mail servers authorized by example4.com send mail
claiming to be from example4.com, then just don't send emails with 2822
"from: (_dot_)(_dot_)(_dot_)(_at_)example4(_dot_)com". We don't need to burden
the receivers, we just
need to accept responsibility for our own mail.
Also, if we establish authority, and someone, say Amazon.com, sends mail
with 2821 saying it's from Amazon.com, but 2822 saying its from
Microsoft.com, and we weren't authorized by Microsoft to do so, then we
just committed mail fraud and will be criminals.
I strongly believe 2822 checking is beyond MARID, but I think I came too
late to that discussion.
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.
Why do we publish acceptance crieria? Isn't a message "550 (or whatever)
Sending denied because your shirt is blue" during the SMTP conversation
enough?
esp.com should just send the message. When it fails, they bounce the message
back to the original sender with an explanation. "It couldn't send. The
server said "550 Sending denied because your shirt is blue."
Besides, publishing acceptance criteria is WAY beyond the MARID core
concept.
Authorization, authorization, authorization! Can this host send email for
this domain? Yes or no? That's it!
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, you guys have already thought of almost everything. Meng and you and
the others have done a wonderful job of critically thinking through every
situation that could possibly arise. You have taken the problem set to the
very core issue (authentication), and worked strictly in that realm. All
the "extensions" these guys come up with are out of the problem scope and
should be handled elsewhere.
Don't underestimate yourselves.
I see that all of the special situation are situations that want something
above and beyond SPF. These things - accreditation, rate limiting,
automated abuse reporting, and acceptance policies - are nice, but they are
beyond MARID. They shouldn't piggy back on SPF records. They belong
somewhere else.
So my response to all of these situations was "SPF for authorization;
something else for something else." SPF as it is now is fully appropriate.
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA0e92BFeYcclU5Q0RAl3JAJkBt7tx/HBC3LCbfdC/Dkp/fcX/CACgpZzl
537O9TJ3x+NfVN3LWcbOTXc=
=5rXg
-----END PGP SIGNATURE-----