Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
When transparent interception is not used by network providers, Trojans
are free to submit mail from compromised machines without detection.
Which would appear to be outside of the scope of MARID.
Sender-ID attempts to change the paradigm of being able to use a mailbox
address as an identifier from any point of access.
That's only part of the truth. It changes the paradigm of being
able to use SMTP from any point of access to submit messages to an MTA
you don't have a previous relationship with, UNLESS the domain hosting
your mailbox (as determined by PRA) publishes a policy saying you are
permitted to send mail. The additional qualifiers are part of the
proposal, and leaving them out distorts any description of the
proposal.
I still like Hadmut's comment in his RMX draft, and think it's
generally true: If you (i.e. an administrative locale) are not going
to accept mail via SMTP, you shouldn't be sending mail via SMTP.
We've had SUBMIT for years. Let's encourage people to use it, and
leave MARID to address the issue of enabling sending MTA's to
accountably communicate with receiving MTA's.
Just as these Trojans exploit thousands of mailbox addresses, these
mailboxes can be culled from a list with "open" records. There would be
no single DNS to enable a shut-down. In addition, these mailbox records
and DNS servers likely represent legitimate users. These users would
react to retaliation tactics,
Like the DNS owners realizing that their bad policies are giving
them a bad name, and updating their policies?
You're assuming that the only possible method of dealing with bad
policies is for a third party to "retaliate". I see that assumption
as unnecessarily pessimistic.
Unlike Sender-ID, CSV does not change mail paradigms
Sender-Id interacts with only the parties involved in an SMTP
conversation: sender, receiver, and (as a new paradigm) the domain(s)
who's names are (ab)used in the conversation. In that respect,
CSV-CSA is identical.
As providers are not required to create an "open" list to
authenticate the MTA when using CSV and MPR, there is no record
available to enable an exploit.
Other methods do not require an "open" list, but they do permit it.
In that way, they are more flexible than CSV and MPR, and therefore as
a side effect, more open to abuse.
These are common trade-offs in protocol design. We need
quantifiable reasons to pick one design over the other. Some
proposals have been deployed for many months, and other have not.
This difference makes it difficult to quantitatively compare methods
as implemented.
Alan DeKok.