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

[Douglas Otis <dotis@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx: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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx?

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@xxxxxxxxxxx" 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