On Thu, 2004-07-29 at 07:35, Rand Wacker wrote:
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*.
I did say some. BATV would allow more immediate benefits as it could be
acted upon by either end. It would be more effective at the sender,
however.
This is lost with Sender-ID.
This wasn't the goal of Sender ID.
We agree Sender-ID does not stop the bounce. I'll bite, what is 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?
Not everyone uses a null RFC 2821 MAIL FROM when they bounce.
Determining a bounce then requires RFC 2822 checks of the From or
Subject headers. This is not a solid basis for rejecting a message
however. The act of the bounce is best known by the sender, in this
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 accommodate an address-based white-list as well?
Specifically, addresses that users see/can see more readily than the
Envelope From?
Is the PRA the same as the RFC 2821 MAIL FROM? Of course not. The
check needs to be based upon an assertion made by the list. A goal to
block the bounce, if the return path is spoofed, can not rely upon a
list intended for a different purpose.
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.
How are the results of this decision reported to the sender? Will mail
simply go missing, if placed in a folder flooded with other junk?
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?
The EHLO domain allows for a stronger level of authentication and
authorization, than an RFC 2822 identity allows (without the aid of
digital signatures) as the EHLO domain can be authenticated directly
against the remote address of the current connection. Rejection based
upon RFC 2821 identities can also conserve network resources. RFC 2822
identity checks will never conserve network resources. Killing the
connection is not a suitable solution as some advocate when rejection is
based upon an RFC 2822 identity.
The RFC 2821 MAIL FROM path is often spoofed as a means to skirt
accreditation checks based upon the remote IP address or, with CSV, the
name of the EHLO domain. There is a need to curtail this practice.
BATV could do this very quickly, but SPF did have merit in this
respect. Sender-ID does not, as we agree.
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 indicate the domain accountable for permitting access
to the mail channel. Sender-ID can not check against the source of a
message, if introduced inside an administrative network or region of
MTAs. As such, it would be impossible to attribute any domain as being
accountable, as this presumes an unverifiable assumption of security.
Also, as shown by a Sender-ID bounce technique, the wrong domain could
be credited for sending the message. It is also very likely, the domain
assertion would be nebulous. What does ~, ?, +all, TempError, or
0.0.0.0/32 mean with respect to accrediting a domain?
In the case of the BATV and a DomainKey, that is missing is a nounce. A
short term blacklist of timestamps with BATV would exclude a 'replay'
attack, but could not be used to accredit the domain. The Yahoo
DomainKey or Cisco Identified Internet Mail signatures of the message
would be strong enough to accredit the domain. These schemes would
still benefit from a lightweight check of the sending domain however.
Sender-ID itself may also need lightweight protections.
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.
Those systems that use CSV, will identify themselves as a source. If an
MTA wishes to enjoy name accreditation, perhaps to bypass filtering or
Sender-ID checks, there would be motivation for publishing the SRV
record that enables this method. A name based accreditation could be
beneficial without 100% participation. CSV-CSA is simple and does not
add a single DNS query beyond the current SMTP protocol. CSV could
eventually amend RFC 2821 as a means to repair the current defect
preventing SMTP client authentication (with authorization added as a
means to thwart Trojans).
> There can be no solution without this information.
We may be looking for solutions to different problems then.
I'll wait to see if I can understand the goal of Sender-ID first.
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?
It would be a nightmare attempting to make sense of Sender-ID domains
from an accreditation perspective. There are many ways Sender-ID itself
can be spoofed, not to mention many nebulous levels of Sender-ID
assurances about the domain. I see problems with an algorithm that
ignores which header type was most recently applied. I doubt anyone has
given this much consideration. Spammers will be quick to exploit
exceptions and learn intra-domain relationships published in this
records. Accreditation is about controlling access at the domain
level. Sender-ID is about grading mail ignoring the channel granted
access. These concepts are incompatible. Would you allow a retailer to
complain about a bad credit card, if they never checked the identity of
the card holder?
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.
I see name accreditation or history as a means of establishing a chain
of trust. A retailer not only trusts a credit card, they are trusting
the holder of the card. In general, they are trusting the system
represented by the card. Only administrators of domains permitting
access will be able to curtail high levels of abuse as seen today. Just
as accreditation allows access to a credit card, the same approach can
work for mail. Those domains that allow abuse, will themselves loose
access. Showing little history could mean little access. This is a
model that works. If there is a crime, there is also an authenticated
and authorized domain name holding the logs with CSV.
-Doug