ietf-mxcomp
[Top] [All Lists]

RE: Does marid-submitter-02 really make sense?

2004-08-12 18:38:41

On Thu, 2004-08-12 at 15:59, Mark Shewmaker wrote:
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.

I do not understand why you see a network service provider monitoring
outbound mail as being incompetent.

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.

So is a judge.

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.

By isolating to the Sender-ID, which may be a small percentage of the
traffic traveling through a shared MTA, even should the provider be
extremely diligent, this domain may become exploited.  It is not the
same problem as checking the host by IP.  The IP properly identifies the
mail stream.  If there is an error that blocks such a shared MTA by IP,
the problem will be corrected quickly.  Sender-ID allows the domain to
be exploited, isolated, blocked, and ignored.  Ouch.

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.

Some network providers have their routers redirect the destination
address for port 25 connections to their SMTP server to monitor the
traffic.  This is a competent and effective means to quickly identify
and remove egregious abuse by checking SMTP error logs.  Sender-ID could
fully validate for the wrong party however.  

Sender-ID does not stop phishing, 

Well, sender_agents would help in the phishing area.  :-)

Something like Identified Internet Mail would help.  I don't know what
you mean by sender-agents.  Do you mean a Certificate Authority?

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?

The identity will always be in question when over a shared MTA.  The
danger is the inevitable law suit, if the wrong party is identified and
hammered by this mistake.  

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.

No. You can NOT trust the PRA.  PRA is potentially comprised of a large
set of domains.  The domain indicated could be any of a few hundred or a
few thousand domains.  The recipient would be unable to determine when
this could be the case!

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.

If you are the one claiming the PRA to be untrustworthy, how would you
know when it was safe to make such an assertion?

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.

Sender-ID does not provide safe measures for repudiation assessments. 
Sender-ID does not authenticate senders, it provides a sloppy sorting of
senders.  Sender-ID will not fend off the onslaught unless having more
folders is a defense.

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.

Sender-ID does not help in this battle.  It is not a good tool but
advocates removal of good tools.  Sender-ID will not enable enforcement
of any policies, but will break mail and cause people to use more and
more mailboxes to identify themselves.  How does that help?

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?

The reputation service providers.

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! 
:-)

I agree.
 
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.

The PRA can not be trusted.  The PRA can not be used to identify
miscreants.  The miscreant may be spoofing as
trustworthy(_at_)trustworthy(_dot_)com and pass with flying colors.   

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.)

If you wish to have a basis for repudiation, start with an identity that
can better trusted.  How about
trustworthy(_at_)trustworthy(_dot_)com:mx01.really-big-isp.com where the
authenticated EHLO domain becomes part of the identity. To process this,
mask the sub-domain of the EHLO response.

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.

This conclusion could be wrong.  It depends upon the level of exploit
and the relative traffic from the server.
 
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.

You are suggesting it is okay to block those that might share an MTA
server?  Better to use a crowded domain then?

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.

The PRA can not be trusted.  What assertion can be made using a tool
that can not be trusted?

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?

There is no means to know the level of trust to place on these
assertions.  It would be foolish to think gaps in these assertions will
not be exploited. 

(Claims being "I got this message from someone(_at_)example(_dot_)com" 
headers in
the message body.)

You are assuming a mapping that can not be verified. There is no way to
know if that is a good assumption, even if it passes all the tests.

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 seems your only defense would be to always use a single recipient
limit if you refuse to merge a per user white-list. If the cost for that
feature is enough, you should be able to detect abuse by way of logs to
make this method of attack rare.  As I said, BATV ends this without a
large adoption.

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.)

As I said, it seems your only defense would be to always use a single
recipient limit, if you refuse to merge a per user white-list.  It would
be foolish to expect cooperation if this were an attack.

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.

I suspect this will be the standard practice used by all providers. 
Prepend a Resent-From to quell support calls.  Is this a good practice? 
The shortest path would be to stop at the EHLO domain and ask if the
From is part of that set.

-Doug