Re: [Endymail] Improvements to S/MIME

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Sep 15, 2014 at 12:21 AM, Tom Mitchell <[e-mail]> wrote:
> 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.

That is a good argument, but the one I was making is that we can't
hope to solve routing security anyway unless we have volume.

It is much easier to hide in a jungle or a forest than a flat featureless plain.