[81758] in North American Network Operators' Group
Re: ISP phishing
daemon@ATHENA.MIT.EDU (william(at)elan.net)
Wed Jun 29 07:34:44 2005
Date: Wed, 29 Jun 2005 04:33:51 -0700 (PDT)
From: "william(at)elan.net" <william@elan.net>
To: Mike Leber <mleber@he.net>
Cc: Tony Finch <dot@dotat.at>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.21.0506290310230.23296-100000@ruby.he.net>
Errors-To: owner-nanog@merit.edu
On Wed, 29 Jun 2005, Mike Leber wrote:
> See my other email in regards to this mobile user strawman argument.
> Look in the archives for the same arguments against closing open relays.
Current mobile-user arguments against SPF do indeed remind of the anti
open-relay battles 5-8 years ago. Not only that but often enough its
the same people who are doing this arguing ... (just look at the main
ietf mail list and you'll see what I mean).
> If Alice wants to forward alice@alumni.miskatonic.edu to
> alice@personaldomain.org and use SPF or MX+ with alice@personaldomain.org
> presumably she won't block email from her other account and she can check
> if she got it right really easy by sending email to
> alice@alumni.miskatonic.edu.
Unfortunately per-user filters for SMTP transmission are notoriously
difficult to implement (especially on large scale). Plus you may not
be able to say that email came in forwarded just from SMTP transmission
(forwarders often do not leave its own marker, you can try to identify
forwarder by EHLO name but that may not be forwarder by some kind of
outbound relay server on the forwarding network site).
Another issue is that are doing the forwarding are the ones that
are most often least maintained as far as upgrading software and
enabling new SMTP features. As a result an idea that we will ask
all forwarders to change and identify themselves in forwarded mail
can not happen as quickly as path authentication proponents want.
Now I did propose one solution to this - a way to bypass forwarders
by having origin mail servers add crypto signatures with their own
hostname serving as base and then tie in further path authentication
to cryptographically verified hostname (see paper, I previously
posted, quick link at http://purl.org/NET/pacap), and I have more
hope in another system that I'll get to later this year.
--
William Leibzon
Elan Networks
william@elan.net
