Re: [Endymail] Improvements to S/MIME

[Tom Mitchell <[e-mail]>]

On Sun, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker <[e-mail]
> wrote:

> On Sun, Sep 14, 2014 at 4:13 AM, Wei Chuang <[e-mail]> wrote:
> > On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch <[e-mail]> wrote:
> >> On Fri, 12 Sep 2014 19:48, [e-mail] said:
> >>
> >> > 1) S/MIME doesn't fully protect users mail envelope metadata.  For
> >> > example
> >> > the recipient and envelope-sender must be visible to the intermediate
> >> > SMTP
> >>
> >> If you want that, it is easy to put the messaqge into a message/rfc822
> >> mail container and use faked subject and other mailer header.
> >
> >
> > Right I agree that there is a RFC5751 sec 3.1
> > (http://tools.ietf.org/html/rfc5751#page-18 )
>
...........

> I suggest that we stick to exchanging endymail with disclosure of the
> routing information before we go on to the traffic analysis prevention
> problem.


Yes...
One of the issues important hint for spam identification is routing
information that  is impossible
from the stated sender.   Prior to eliminating routing information it seems
important that
the message be self identifying and contain enough validation information
to make opening
a message from "Bob" a safe bet that it is infact from "Bob".  If done
correctly transport
software can inspect a message and safely ignore adding or checking headers
because
crypto and message type removes this need.

The reverse is not true as it opens a door for spam abuse.

-- 
  T o m    M i t c h e l l