ietf-mxcomp
[Top] [All Lists]

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

2004-08-12 20:39:31

On Thu, 2004-08-12 at 21:38, Douglas Otis wrote:
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.

I never said anything like that.  (At least I hope I didn't.)

(Although with Unified-SPF, I would expect to look forward to a day in
which ISPs can safely remove outbound mail blocks at residential
addresses.  Separate issue though.)

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.

Then if the shared MTA is exploited, then domain's reputation will
suffer, even if the domain didn't actually intend to be a victim.

That's simply the way things are.  People will not think as highly of
that PRA afterward, for some amount of time at least, and won't put as
much trust in their claims.

People will alter their opinions.  I'm sorry if that bothers you.

Now, if the PRA tries to start suing people who have started to think
less highly of his purported claims, then yes, I think that's unfair and
uncivilized behavior on the PRA's part.

I don't believe in thought crimes.

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.

Yeah--ouch!

I can only conclude that people who put themselves in such a vulnerable
position are likely to quickly correct the problem when their
vulnerabilities are exploited--after which their reputation should
improve.

Or they'll go out of business.

Or they'll go to the courts, at which point I can only hope that their
reputation would plummet.  (I for one try to avoid doing business with
companies like that--companies that won't admit, stand behind, and
correct their problems.)

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.  

Oh-okay.

Well, if it could fully validate for the wrong party, then either the
MSP is allowing cross-customer forgeries, or the purported sending
domain has their SPF records set up poorly.  (Or both.)

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?

It's a modifier I've been pushing for a few months as a way to get
SenderID to fully address the phishing problem, to little avail
unfortunately.

(I'm frustrated at my inability to stir up interest so far, as IMHO
sender_agents would make SenderID *FAR* more useful.)

See:  http://www.imc.org/ietf-mxcomp/mail-archive/msg03112.html

Here's the idea in a nutshell:

1.  Postulate:

    Authenticating the return path is a separate
    sort of thing from authenticating the
    forwarding path of purported (re) senders.

    A.  Classic SPF validates the return path.
        SES/BATV validates the return path.

    B.  Sender ID attempts to validate the
        purported (re) senders, but only validates the
        latest purported (re) sender directly.

    C.  Phishing detection detection has to do with message
        body tests, not envelope tests, hence if it were to
        be included in one of Classic SPF or SenderID, SenderID
        is the logical choice.

        So there's a question of how to put such a test in SenderID.

2.  Postulate:

    Since Phishing/re-sender tests and return path bounce-a-bility
    tests are mostly uncoupled from one another, so should be one's
    response to a failing result of such tests.

    A.  If I get a message where return-path tests FAIL,
        then I should reject the message.

        It doesn't matter if the failure is determined via
        classic SPF tests, or via SES/BATV tests.

    B.  If I get a message whose contents (including body headers)
        show it to be internally inconsistent (a type of message
        corruption) or otherwise a type of internal forgery, I
        should reject the message.

3.  The type of phishing I'm addressing is where someone claims to 
    send a message in a body header From:'s name, but From: isn't
    okay with that.

    *OR*

    A later PRA claims to send a message in the name of a previous
    PRA, but the previous PRA isn't okay with that.

So I proposed a sender_agents modifier that allowed users to say that
they don't allow other people (PRA addresses) to speak for them in
general, and to give an exception list of addresses that do.

So if I got a message From: you, but with a Sender: of
good-friend-of-yours, I could do a query to see that you trusted this
good friend of yours, so that I should trust the message to be genuine
from your point of view, were I to trust that the message really came
from your friend.

That would mean that if I got the message directly from your friend, I
could trust it.

Or, if your friend sent the message to my old, trustable ISP, that
forwarded it to me, since you had whitelisted your friend going forward,
and I had whitelisted my old account at my old ISP going backwards,
those two trust chains meet without any PRA in between them, and I can
(mostly) trust the message that I ended up getting to be genuine.

Or, if you say you participate in sender_agents, and I get a message
with body-header From: you, but Sender: evil-person(_at_)example(_dot_)com, I 
know
I can reject the message, even if SenderID said it really came from
evil-person, and even if classic-SPF said the return-path was good. 
(Unless I had white-listed evil-person for some reason--but obviously no
technical solution can overcome poor judgement in choosing friends!)

Anyway, it's only slightly more complicated than that--in ways you can
guess really, to accommodate multiple forwards and mailing lists.

But the upshot of it is that sender_agents can stop phishing to a large
extent, among participating players.

(Ie, if paypal.com published a sender_agent modifier within an spf
record, recipients who took advantage of it could have messages they
would have received with body header From: billing(_at_)paypal(_dot_)com and
Sender: forger(_at_)example(_dot_)com rejected, ***without being dependent upon 
a
single blocklist to see that forger(_at_)example(_dot_)com was 
untrustworthy***. 
However, they would be dependent upon blocklists or a keen eye to see
notice forgeries of the type of billing(_at_)paypa2(_dot_)com, or
billing(_at_)paypa1(_dot_)com (with numeral 1 instead of letter L.))

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. 

Sorry--if my reputation system makes me give a poor reputation to
someone because they're using a shared MTA that allows cross-customer
forgeries, then my reputation system is doing it's job.

I simply won't think highly of people who willingly expose themselves to
such vulnerabilities.  It's unfortunate if I can be prosecuted for such
a thought crime.

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.

If someone else can spoof trustworthy(_at_)trustworthy(_dot_)com, then I hope my
reputation systems will assign a poor reputation to the trustworthy.com
domain, because any claims of anyone to be from there aren't, well,
trustworthy.

The fact that trustworthy(_at_)trustworthy(_dot_)com tells me to trust that a
message really comes from him if it comes through a specific IP still
doesn't mean I should trust such claims if I know that that specific IP
itself isn't trustworthy.

(Ie, if trustworthy is a friend of mine who I happen to trust 100%, and
he trusts a specific IP 100%, but I only trust it 10%, then I should
only trust messages from through that IP, where I can only authenticate
via that IP, by just 10%.  Goofy wording, but you get the idea.)

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 makes sense, except for the EHLO bit, (getting people to give
honest EHLO strings is going to be another herculean effort, GRRR),
but..the real reason I wasn't pushing for that level of things is that I
don't expect people who report problems to, on the whole, be able to
reliably report the sending EHLO domain or even IP.

Plus--I expect that people will move to more trustworthy MSP's that
don't allow cross-customer-forgeries, so I'm guessing that that level of
resolution will not only become unnecessary, but end up being too much
work for people to be willing to bother with.

You are suggesting it is okay to block those that might share an MTA
server?

If it's an insecure MTA, yes:  Today I block MTA IPs that are known to
be compromised and spewing viruses.  There may be trustworthy people
using those IPS--too bad.  :-/

But I don't see any reason to block mail from a shared MTA that doesn't
allow cross-customer forgeries.

But one that does allow those forgeries, and for whom that's become a
practical problem, yeah, I would tend to start wanting to block other
domains using that MTA.  (From a practical point of view it's not a
binary thing--some folks would allow a bit and then notice and correct
the problem, and for other's it's a technical possibility but a
practical impossibility to any large extent.)

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.

Yeah.

And to be fair, if most MTA's switch to using SUBMITTER anyway, then
it's mostly only the forgeries that become expensive.  And I guess it's
probably worth the expense there.

As I said, BATV ends this without a large adoption.

No it doesn't.

BATV and SES only help for domains in which the purported sending domain
participates.

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.

Correct.

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? 

It's a lazy way for recipient MTAs to operate, against the spec but
somewhat compatible with it as far as end results go, but I hope they
won't *actually* do this.

The shortest path would be to stop at the EHLO domain and ask if the
From is part of that set.

I don't see how that would help--the server sending the message can be
different from the domain listed in the return path.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com