On Thu, 2004-08-12 at 13:09, Douglas Otis wrote:
On Thu, 2004-08-12 at 04:39, Mark Shewmaker wrote:
On Wed, 2004-08-11 at 13:03, Douglas Otis wrote:
A public list assessing these identities used to block mail would be
doomed. Abuse *beyond* the domain holder's control would elicit a legal
challenge to any assertion of their reputation that stops their mail.
Then people who live in jurisdictions where such is possible will
suffer, but that's no reason to make those who live in more civilized
parts of the world suffer along with them.
This does not provided the domain holder any alternative!
Sure it does--use a competent mail service provider.
They have
done nothing wrong, and yet a listing based upon Sender-ID claims they
did. As a result, their mail is stopped. What is fair or civilized
about that?
It's perfectly fair and civilized.
If you purchase outbound SMTP service from an incompetent mail service
provider, their incompetence will mean that you can appear to be
engaging in activities that you're not intending to engage in, and
recipients will not have any reliable way of telling the difference
between your activities and your MSP's actions.
That will affect your reputation, no question about it .(Think of the
old AEGIS (sp?) IP-based blacklistings a few years ago.)
You always have a recourse of going to a better mail service provider.
These transparent interception techniques ARE civilized and
DO provide significant relief from the amount of abuse suffered upon the
world.
I don't know what "transparent interception techniques" you're talking
about.
Sender-ID does not stop phishing,
Well, sender_agents would help in the phishing area. :-)
Obviously, domains whose outgoing MTA service is an MTA that allows
cross-customer forgeries will likely suffer in reputation.
Reputations based upon Sender-ID would never point to their servers as
being at fault. Here lies the rub. Sender-ID can not be trusted, and
yet the party at fault can not be identified.
Why can Sender-ID not be trusted in this context?
Yes, I agree that it "cannot be trusted" to solve the entire set of
problems that it was purported to solve, as well as the problems point
out that it won't solve, but it can still identify PRAs--and so if you
have a reputation system that you can query about PRAs you've
identified, that reputation system could tell you whether you can trust
claims from those PRAs.
In the case of an untrustworthy PRA, I wouldn't care very much which
particular server that message came from, if claims purportedly made
from that PRA were said to be untrustable.
That's quite as it should be, IMHO.
If you were not wishing to take any action against spam, perhaps.
I don't care to take any direct action against spam, no. (Direct action
being things like initiating lawsuits, or even spending hours on the
phone trying to get network providers to cut off accounts.)
I just want systems that authenticates senders in multiple ways, and
other systems that provide various measures of reputation against
senders, with an end result that recipients by and large aren't affected
by the onslaught of spam attempting to reach them.
Taking direct actions against spam is a lot more work, and I'm lazy.
I'd rather everyone be able to avoid the problem, let forgers and
spammers slowly find it harder and harder to acquire new victims, and
let them move to more lucrative (and hopefully more honest) pursuits.
If honest-company.com authorizes incompetent-isp.com to send mail on
their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com
use their servers to forge emails in honest-company's name, well of
course honest-company's reputation will suffer.
Based upon which reputation service? These providers will spend their
^^^^^^^^^^^^^^^
Who do you refer to here?
scant time in court, if they were foolish enough to depend upon the
ability of Sender-ID identify miscreants.
Spending their scant time in court? Talk about unfair and uncivilized!
:-)
There are multiple measures of reputation involved here--the one I
thought we were talking about here is whether you could trust claims
purportedly made by a given PRA. That's quite a different thing from
whether they're a "miscreant" by any other measure.
One can only hope for the development of a distributed reputation system
into which reporting participants could securely
anonymously/pseudonymously enter information. I only hope it's
mathematically possible to do some sort of (buzzword alert) combination
of zero-knowledge proof and automatically-maintained webs of trust
between pseudonyms, (separate writing-versus-reading webs too
hopefully.)
That will happen now, just more indirectly, via IP-based block lists.
So you are advocating IP based blacklisting as the solution?
It's the substandard solution available now.
It can happen after SenderID becomes popular, (assuming people do
classicSPF tests to of course), via domain-based (and email based?)
block lists, for domains whose outgoing smtp services are hosted at ISPs
allowing cross-customer forgeries.
This sounds like mumble, hand-wave. Are you advocating to block all ISP
that take measures to control spam, in favor of this new goal of
restricting the use of RFC2822 From Mailbox Domains?
You're not making sense. Where do you get this "block all ISP" bit?
I just expect that people who use ISP/MSP's that allow cross-customer
forgeries will end up with worse reputations than if they went to more
competent ISP/MSPs.
Sender-ID must not be trusted as explained. Expectations of a
reputation service used against the PRA will not provide satisfactory
results. In addition, complaints raised as a result must be ignored.
If to provide a reputation service, it must be made clear PRA is not a
valid basis for registering complaints nor blocking spam. Is there a
better way to make that point clear?
I don't know, but it still doesn't make sense to me.
Let's say that you use a reputation system says that the PRA
"trustable-person(_at_)untrustable-msp(_dot_)com is not trustable.
Then even if you get a SenderID PASS on that PRA, unless you've
overridden things with a white list on your end, why should you trust
claims seemingly coming from trustable-person(_at_)untrustable-msp(_dot_)com?
(Claims being "I got this message from someone(_at_)example(_dot_)com" headers
in
the message body.)
As one of your users have vouched for this sender, a
bounce should not be a problem, as this is not a bad actor.
I wouldn't assume the "not a bad actor" bit--we're talking about
potential attack vectors, so by definition we have to assume that anyone
could be a bad actor.
You have allowed a user to create a white-list. If you discover they
are white-listing an egregious spammer sending in bulk to non-existent
users in your domain, you may reconsider allowing this specific
white-listing or perhaps dropping this user. If these messages are to
valid users, then it does not sound like a typical spoof bounce attack.
Of course it's not a typical attack nowadays. We're talking a weakness
in a system that's not yet in place, and how folks can exploit that
weakness.
No one's going to be attacking the weaknesses of a system before the
system is widely implemented, hence those attacks won't be they typical
ones right now.
It also appears they do not appear on an IP blacklist.
True.
I assume you are suggesting this spammer also knows valid accounts on
your system, but also knows that these other users will be rejecting
their message based upon a filtering result (not a blacklist).
That's one way, yes. (I don't see a real difference between the results
of "a filtering result" and "a blacklist" btw.)
Hence the need for BATV?
SES/BATV is a protection a *sender* can put up to prevent bounces to
their own domain--and it's fantastic for that!
But as a recipient, you can't use SES to solve a problem, because you
are powerless to tell the sender to re-send with an SES-signed return
path. (Well, you could refuse all mail that doesn't have either
Classic-SPF PASS results or validated SES-or-BATV return paths.)
The danger, as
stated, is that if only submitter were checked, it would not matter what
was contained within these headers and the user would be under the false
impression at least one of the headers had been checked. What had been
checked will remain a mystery.
A receiving MTA that didn't want to check could always just prepend the
SUBMITTER in a Resent-From body header, and then MUAs would be able to
see what was verified.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com