Douglas Otis wrote:
On Wed, 2004-07-28 at 11:22, Rand Wacker wrote:
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).
SPF offered some relief, if the MTA creating the bounce checked the
destination domain records for valid sources of the message.
Again though, this requires *every* MTA that might generate a bounce to
deploy SPF checking, *everywhere*.
> This is lost with Sender-ID.
This wasn't the goal of Sender ID.
A solution for this problem could be found through
a combination of SPF and BATV, where BATV is less disruptive.
If an individual sending site deployed BATV wouldn't that let them
determine what bounces were genuine and which were forged from the
outside? Why would they need SPF *at all* in that case?
SPF accommodates an address based white-list, but such a list would be of
less use, with CSV offering names.
Doesn't Sender ID accomodate an address-based white-list as well?
Specifically, addresses that users see/can see more readily than the
Envelope From?
Should end-users or the MTA make accept/reject decisions?
This question seems out of place. But decisions should be made by some
automated system, probably near the gateway, operating on behalf of the
wishes of the admins/users.
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.
For what technical reason is it best based on the 2821 address?
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.
Agreed.
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?
OK, I agree with everything you say here as well. Doesn't almost every
proposal put forth here (including Sender ID and DomainKeys) give you a
verifiable domain to check the history of?
Sender-ID does not identify which domain allowed introduction of abusive
mail.
Without 100% publication of DNS records for sending domains, *none* of
these solutions will be able to identify where all mail came from.
> There can be no solution without this information.
We may be looking for solutions to different problems then.
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.
Agree with the latter, disagree with the former. Sender-ID can be used
to verify the sending domain for purposes of reputation checks just like
you say. Is your concern with it the use of Resent-Sender and Resent-From
And, FWIW, neither SPF nor Sender-ID will ever be able to tell you any
more than the most recent domain to forward a message to you, so in the
case of messages that go through multiple hops to your gateway, you're
going to be checking the reputation of any service that may be
forwarding to you.
-Rand