On Sun, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker <[email protected] > wrote:
> On Sun, Sep 14, 2014 at 4:13 AM, Wei Chuang <[email protected]> wrote: > > On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch <[email protected]> wrote: > >> On Fri, 12 Sep 2014 19:48, [email protected] 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
_______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
