On Thu, 2004-07-29 at 17:45, Rand Wacker wrote:
On Thu, 29 Jul 2004, Douglas Otis wrote:
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.
Right, so it seems that BATV could be a *much* better solution to the
joe-jobbing solution in the short term than SPF, precisely because BATV
requires adoption by exactly *one* site, the sender that wants to discard
bounces to them of forgeries. To completely solve joe-jobbing for any one
site, SPF requires 100% adoption across the entire Internet.
(This is not to say that SPF may have other good properties, I'm just
hearing a lot of "its all about stopping joe-jobbing" comments)
We agree Sender-ID does not stop the bounce. I'll bite, what is the
goal of Sender-ID?
I refer you to the MARID charter and the marid-core draft.
The core-02 abstract:
Internet mail suffers from the fact that much unwanted mail is sent
using spoofed addresses -- "spoofed" in this case means the address
is used without the permission of the domain owner. This document
describes the following: mechanisms by which a domain owner can
publish its set of outgoing MTAs, mechanisms by which SMTP servers
can determine what email address is allegedly responsible for most
proximately introducing a message into the Internet mail system, and
whether that introduction is authorized by the owner of the domain
contained in that email address.
The specification is carefully tailored to ensure that the
overwhelming majority of legitimate emailers, remailers and mailing
list operators are already compliant.
CSV publishes outgoing SMTP servers. A "spoofed" address for most would
include the RFC 2821 MAIL FROM, but yet this address is ignored. CSV
and BATV meets the goal of finding prior compliance far better than
Sender-ID.
Now here is an interesting sentence fragment.
mechanisms by which SMTP servers can determine what email address is
allegedly responsible for most proximately introducing a message into
the Internet mail system, and whether that introduction is authorized
by the owner of the domain contained in that email address.
Clearly, in the case of a bounce containing Resent-Sender, Resent-From,
or Sender, this proximal goal is missed. Also, can Sender-ID claim to
have met this goal, if the rating is other than Pass or Fail? No, and
yet there are many rating levels?
Sender-ID allows mail to traverse or be emitted by many differing
domains of those referenced by the PRA. It would be an over statement
to suggest permissions of the PRA can be verified with any certitude.
SMTP is simply not secure enough to make this assertion, especially when
the specific SMTP server domain is ignored. There are methods that can
safely reach to the RFC 2822 From. Methods like Identified Internet
Mail can accomplish this goal, with the requisite certainty. Sender-ID
can not.
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)
The RFC 2822 identity in a message is *exactly* the same regardless of
whether it is authenticated by a crypto-based solution, an IP-based
solution, or not authenticated at all.
An RFC 2822 identity may relate to an IP address of an SMTP server, but
at far greater distances, if compared to the EHLO domain. This is
important in both the immense scale required for such a relationship,
the complexity deriving the relationship, and the assumption of security
needed to assert the relationship. Any claims of having verified or
validated the RFC 2822 From would be irresponsible, in my opinion. The
PRA is not limited to just this From header, nor should the channel be
considered secure enough to make such claim.
We are definitly talking about two different goals, as I want to
authenticate the sender of a message, you want to authenticate the owner
of a channel.
Sender-ID does not indicate the domain accountable for permitting access
to the mail channel.
True. But again, that is not its goal.
I would expect an ISP response to the complexity of Sender-ID, would be
to add Resent-From to all outgoing mail. This would allow customers to
continue normal habits. To arrive at a point where a message can be
rejected or accredited, barriers must be removed that would prevent
certitude in that process. A greater distance between the the
associations being verified, reduces this certainty. Evidence of this
reduced certainty is documented by the many gradations that may result
with Sender-ID. If the goal is to validate the RFC 2822 From, then do
this in a reasonable fashion. The scope of any simple validation should
not extended beyond the most immediate, being the MTA in this case.
This is the charter, is it not?
Sender-ID can not check against the source of a message
The *original* source of a message. It can check against the *most
recent* source of the message, to exactly the same level of assuredness as
SPF or any other IP-based system.
I do not agree with that statement. By not going beyond the host being
authenticated and authorized, there is a significant difference between
the quality of the assurance from CSV versus Sender-ID, if to establish
accountability of the entity granted access. Access is the commodity of
accreditation and the tool to enforcement.
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.
When I say "accreditation and reputation checks" I am referring
specifically to querying a network service to ask about historical
behavior of the particular sending domain. Based on previous comments I
think you may be using accreditation to mean something different.
With Sender-ID, I see a complex record set that may include many
different domains. To suggest that I should accredit the domain seen in
the PRA misses the purpose of accreditation. Accreditation needs to
assess the policies of the domain granting access to the mail channel.
The scale of this task is great, but resolving to the user would be
overwhelming. There is a cost associated with a domain, there is
virtually none for a user. The scope of the accreditation must end at
the domain, and only relate to their access policies. With Sender-ID,
these messages could be "granted permission" by any number of domains.
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.
I still think we are using the term "accreditation" differently, but I
believe we agree on one thing here, making domains more accountable for
the mail they send. I *think* that you want to do this by authenticating
the channel the domain used to inject a message in to the system. I want
to do this by authenticating the user-visible address purports to be from.
The PRA is not always the user-visible address. By looking to the
user-visible address, you miss what needs accreditation. What domain is
negligent in their access polices? Do their policies control access in
a manner that abates abuse? Looking to the user-visible address makes
this assessment far more difficult. Looking to the user-visible address
makes this assessment far less accurate. Sender-ID does not offer the
tools needed to tackle the problem, as its assertions are too weak and
too vague to be acted upon. It may be just fine, if the goal is to
select a folder. That goal seriously erodes the integrity of the mail
system however. It also places a greater burden upon the recipient. It
does not protect the network. It does not abate the abuse, because
accreditation has become even more difficult.
To be blunt, I think everyone who has actively participated in this group
understands that *any* IP-based solution applied at *any* level can *only*
give you assurance of the most recent hop that a message took. This
applies to CSV, SPF, and Sender ID. This has implications for any message
that takes more than one hop from the original sending domain to the final
receiving domain. All the proponents of these IP-based solutions
understand this and are moving forward knowing full well that they are not
able to authenticate the original sending MTA, domain, or author.
To fully understand the scope of the problem, work only on what can be
assured. Limit the reach to the most immediate with simple measures and
stop trying to indirectly authenticate the user. SMTP was never
intended to preform this function. BATV and CSV can make a dramatic
change without breaking mail, and can be put into play quickly. We can
make a real difference, if to recognize what is within our grasp, and
what is not.
-Doug