"Alan DeKok" <aland(_at_)ox(_dot_)org> wrote:
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.
By attempting to map the mail channel to a mailbox domain, the normal
practices of handling mail are affected. Sender-ID is attempting to use
RFC2822 content as a means of authenticating the MTA. Had the MTA been
directly authenticated, there would not be a conflict which makes this
issue relevant to 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.
The technique of using RFC2822 content to identify the MTA will lead to
errors and is based upon a premise such content has not been spoofed
between MTAs. There is no means within this standard to hold a particular
MTA accountable.
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?
These are not errors of policy. These are errors built into the standard.
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.
Those being black-listed are not provided a means to ensure the integrity
of the mail channel down stream. It could easily be within the recipients
realm that spoofed identities are injected. The indirect method of
identifying the MTA may lead to grevious errors where perhaps legal
retaliation becomes the only available option, should an guiltless party
become blacklisted out of the caviler confidence of the mail channel
integrity.
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.
CSV-CSA deals directly with the entity sending the mail, and not
indirectly based upon RFC2822 content. This restriction placed upon the
RFC2822 content by the recipient with respect to the a prescibed mail
channel is a new paradigm. CSV is still dealing directly with the MTA
without imposing such restrictions and without the possibility of false
implications of responsibilty.
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.
I do not agree the Sender-ID's attempt to make a general rule for all
mailbox domains to be bound to a mail channel is more flexible. In fact,
the desire to prevent phishing and spoofing for finacial institutions, as
example, is better addressed by MPR. MPR is far more flexible while not
breaking mail.
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.
This was my reason for creating a list of features. This effort should
consider the impact of the current mail system and how this transitions.
If there is to be an accreditation system, it better be defendable. I do
not see how one could defend Sender-ID assessments.
-Doug