-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think a general summary for my response is that we have to decide a few
issues.
(1) What will SenderID do? Will it be limited to just authentication, or
will it be expandable in the future? And authentication of what exactly?
The sending MTA, or the sending MUA, or what?
If we decide that Sender ID will only authenticate whether a particular MTA
at an IP address is allowed to send messages for a domain, then Sender ID
is sufficient.
(2) Also, how will we handle complicated and rare situations? Will we try to
write a syntax that handles every imaginable case, or will we accept
limitations to the syntax with the idea that the complicated and rare
sitatuations should be modified?
My responses are embedded below.
On Wednesday 16 June 2004 08:06 pm, Margaret Olson wrote:
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.
I believe that rate limiting should be beyond the scope of Sender ID. For
one, it is better implemented on the sending MTA side. This would be an
implementation detail for the MTA, and requires no external knowledge to
either example1.com or any receiving MTA.
The other possibility is to implement rate limiting on the receiving MTA's
end. But how can the receiving MTA know how many email messages were sent
to other MTAs? How can a receiving MTA trust the number that other MTAs
report to it? These difficulties would greatly complicate Sender ID, and so
should be external to Sender ID.
Thus, no extensions to Sender ID should be created for rate limiting.
The question of accreditation is also posed. How does example1.com become
accredited with accreditors.com? How does accreditors.com inform other MTAs
of their accreditation? How do other MTAs decide what to do with the
accreditation information? Despite any answers above, accreditation has
nothing to do with authorization. Either an MTA is allowed to send email
for a domain or it isn't, and accreditation doesn't affect that.
Thus, no extension to Sender ID should be created for accreditation either.
In summary, no extensions should be made to Sender ID to describe
example1.com's situation.
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.
The problems with receiving MTAs summing up the number of emails sent for a
particular domain are outlined above. Drawing from the conclusions above,
no extensions to Sender ID should be made for this situation.
I believe that entering into a three-way contract like this is difficult at
best. Rather, example2.com would draw up one contract with personalmail.com
and another with esp.com. Besides the problems of getting three people to
completely agree to anything, the technical problem of reporting the number
of emails sent is not a trivial one.
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.
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.
Complaint monitoring is a complicated example. How are we to inform
receiving MTAs that they should send complaints? For what situations do
they send complaints? How do we handle complaint messages to avoid a
situation where complaint messages generate more complaint messages? Are
receiving MTAs obligated to send complaints? How do we verify that
complaint messages are not falsified? Is there a universal standard or do
we have to negotiate a method of verification?
I believe that complaint messages are beyond the realm of authentication
because of the difficulties outlined above. The problems above are almost
larger than the original problem of authentication. If ISPs and ESPs want
to partner and exchange complaint messages, then that is their right to do
so. Encoding such an agreement in Sender ID is not appropriate.
Thus, no extensions to Sender ID are needed for this situation.
Note that rather than monitoring complaint messaging, a more effective
solution would be to audit the email sending facilities of example4.com.
After the audit, strict Sender ID records could be published. Any remaining
email sending facilities will later be discovered via bounced messaging or
human-generated complaints or other signs.
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.
It is the responsibility of the sending MTAs to ensure that email is
properly formatted. Sender ID, I believe, should only be concerned with
authorization.
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.
Acceptance policies are beyond the original premise of Sender ID. I don't
believe publishing such a policy is necessary. Here's my explanation why.
esp.com should send the messages. If example5.com accepts it but later sends
a bounce mesage, esp.com should forward the bounced messages from
example5.com to their customers. If example5.com refuses to accept the
mesage, esp.com will return a bounced message to their customer with the
error message. It is example5.com's responsibility to provide accurate and
descriptive error and bounce messages.
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA1yvIBFeYcclU5Q0RAoFbAJsENmmHSRaTFDh+F18Syb916PMt+gCfUpxT
TDE8nK0+HQxVH5fZhoxWgrI=
=zcKs
-----END PGP SIGNATURE-----