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.
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.
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.
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.
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
behaviour of the particular sending domain. Based on previous comments I
think you may be using accreditation to mean something different.
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.
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.
-Rand