On Mon, Sep 15, 2014 at 12:21 AM, Tom Mitchell <[email protected]> wrote: > 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.
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. _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
