On Jun 21, 2004, at 2:41 PM, Jonathan Gardner wrote:
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.
If the receiving MTA wants to know if this small business sends at a
rate consistent with a legitimate small business or at a rate
consistent with a spammer, then the receiving MTA will want to know the
rates. They will also want to know if the sending MTA accredited as
enforcing sending limits; this is why you need to know things about
both the channel and the sender where the sender and the channel are in
different domains. In many cases, they will be in separate domains;
there are millions of domains that do not run their own MTAs.
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.
The rate limiting needs to occur on the sending side, but the receiver
needs to know what it is.
It is true that we don't at this moment know the specifics of how the
accreditation, reputation, and rate limiting will work. But these areas
are emerging; the fact that we don't have a spec in hand is not a
reason to dismiss the need for them. If anything it's an argument for
flexibility.
Margaret