James A. Donald wrote:
> > In order for [DKIM] to actually be any use, the
> > recipient needs to verify the signature and do
> > something on the basis of that signature -
> > presumably whitelist email that genuinely comes from
> > well known domains.
> >
> > Unfortunately, the MTA cannot reliably do something
> > - if it drops unsigned mail that is fairly
> > disastrous, and the MUA cannot reliably check
> > signatures, since the MTA is apt to mess the
> > signatures up.

Anne & Lynn Wheeler wrote:
> so what if an isp only signs email where the origin
> address is the same as the claimed email "from"
> address.
> then email that claims to be from such an isp, that
> isn't signed, might assumed to be impersonation.

Then you get into the same problem as with SPF.

Obviously the problem can be solved, it is not even hard
to solve, but the solutions we have now do not actually

> ISPs could do ingress filtering where they only
> process incoming email from their customers ...

There are lots of excellent, and reasonably simple
solutions, that work if everyone alters their behavior
except for a few wicked malefactors, and all software is
fixed up so that it works with the new solutions, but
the solutions that are actually under way right now do
not work well when there is a mix of old and new
software, and old and new practices.

In order to get to the end state where email is secure,
each step along the path has to be in the interests of
the individual making the change.  It is easy to imagine
an end state that is better than what we have now.  The
trouble is that part way to the end state also has to be
better than what we have now.

We need a solution that is good for the individual to
implement right now, and also solves the problem if most
people implements it - has increasing network effects.

> ISPs could also start to quarentine unsigned email
> that claims to have originated from ISPs that are
> known to sign email.

But, in practice, domains cannot control the behavior of
people who legitimately use that email domain name, so
people do not in practice follow the sender policy
framework.  If an ISP drops mail that violates another
ISP's sender policy framework, it is intolerable,
because most of the mail dropped will be legitimate.
Filtering has to be done client side, where the client
can judge what is good for him, what works for him.

The solution is for the recipient MTA to add all the
authenticity information that it can get into the mail
headers, and for the client side filtering software to
pay attention to these MTA headers - but that is not the
solution we have.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to