On Wed, 2004-07-28 at 11:22, Rand Wacker wrote:
On Wed, 28 Jul 2004, Douglas Otis wrote:
Although CSV could help make these intra-domain configurations safer,
the problem was about how a resulting bounce is handled. Remember,
Sender-ID ignores the RFC 2821 MAIL FROM. The defense against the
bounce that once justified publishing these records has been removed by
the PRA algorithm.
Doesn't protection against the bounce using SPF-Classic require 100%
adoption to make it work? Wouldn't BATV or some other site-local
protection against joe-jobbing have a more direct impact on this problem
(which, I will note, is not necessarily the problem this group was
chartered to address).
-Rand
SPF offered some relief, if the MTA creating the bounce checked the
destination domain records for valid sources of the message. This is
lost with Sender-ID. A solution for this problem could be found through
a combination of SPF and BATV, where BATV is less disruptive. SPF
accommodates an address based white-list, but such a list would be of
less use, with CSV offering names.
Should end-users or the MTA make accept/reject decisions?
The forward/reverse model for MX records is not symmetrical. Some
'forward path' is visible, but this view is not comprehensive.
Rejection based against a sending domain's 'reverse path' is daunting,
but must be comprehensive. Rejection based upon a sending host-name
falls within an achievable realm for DNS, and ideally accomplished with
a single query, as with CSV.
The host-name relationship broadens to the sending domain within the
realm of accreditation. The quest for a 'reverse path' still does not
permit a decision of whether to reject the message, if to avoid abuse.
A quest to examine content only weakens a decision process with
complexity. The decision whether to reject the message is best based
upon RFC 2821 information. The result should not be a rating for an
end-user disposition of messages. It would be hard to twist the charter
to arrive at that goal.
A standard method to sign RFC 2821 MAIL FROM paths, as with BATV, would
end schemes used by rogue mailers to skirt accreditation. This skirting
takes advantage of MTAs that do not employ history, and a reason for
many spoofed addresses. If the sending domain has a history, acceptance
is based upon the sending domain's demonstration of policy. If the
sending domain does not have a history, then mail could be constrained.
For economies of scale, the burden must be placed upon the sender. This
burden would result from their history of behavior. If the sending
domain is rejected as a result of their accumulated history, then it
becomes their burden as the sender. It must not be seen as a problem
for the end-user to sort, filter, and delete. Grading makes mail
unreliable and eventually useless. History based accreditation is best
done with a known name of the sending domain responsible for policy.
This is the specific aim of CSV. To stop spam or viruses, the question
remains, what is the history of the domain?
Construction of a partial 'reverse path' or examination of content for
filtering does little to abate abuse. The quest for 'reverse path'
based grading begs for restrictions upon end-users to a limited choice
of a mailbox, or forces exposure of an additional mailbox, while
breaking many programs. Freedoms offered by mail can be preserved,
rather than sacrificed for new folders in a mailer program. These
introduced identities resemble a shell game, where the end-user guesses
the significance of different headers, most unrelated to the author of
message. There are straight forward and strong means to identify the
author that do not break mail.
Sender-ID does not identify which domain allowed introduction of abusive
mail. There can be no solution without this information. If a domain
demonstrates a history of neglect, then a growing number of rejected
messages will make economic sense for polices to be repaired. Sender-ID
is useless in this regard. Put the burden upon the sender, and not the
recipient.
-Doug