On 2005-01-09 13:29:41 +1000, Laird Breyer wrote: > On Jan 08 2005, Michael Kaplan wrote: > > > If X sends out a weekly newsletter to thousands of people, most of > > > whom use your system, then X receives thousands of bounce messages > > > back, requiring individual CAPTCHA decoding, followed by individual > > > resending of the message, does it not? > > > > It almost sounds as if you expect most newsletters to get bounced. > > The newsletter will only get bounced if the specific sub-address used by > > the newsletter is deactivated. > > Wouldn't the newsletter operator first have to obtain the specific > sub-address from each receiver (assuming your system is widely deployed) > at least once? That's a thousand bounces (ie number of recipients) right > at the start. Probably not. The User would generate a fresh subaddress and subscribe that to the newsletter. Since Subaddresses are created in "accept everything" mode in Michael's proposal, the newsletter would be accepted without a challenge. Only when the subaddress is deactivated, challenges will be generated. (On a well-maintained newsletter this will probably cause the address to be unsubscribed) However, subscribing to mailinglists may be a bit difficult with Michael's scheme: Lets say, Our user Joe tries to subscriben to the mailinglist <foo at example.net>. So he creates a new subaddress (e.g., <joe.b0263 at example.com>) and enters into a web form or sends it to <foo-request at example.net>. Typically, the mailing-list software will reply with a confirmation request: from: <mailinglistsoftware at example.net> to: <joe.b0263 at example.com>. When Joe replies, his software will generate a new unique address, since he never sent mail to <mailinglistsoftware at example.net> before (e.g., <joe.26ab0 at example.com>). So the Mailinglist-Software will receive a confirmation from <joe.26ab0 at example.com> to subscribe the address <joe.b0263 at example.com>. Some mailinglist software will refuse the request if the two addresses don't match. Even if he manages to subscribe, however, the first time he wants to send something to the mailinglist, the software will create yet another unique address (e.g., <joe.6d7fc at example.com>), since he hasn't sent anything to <foo at example.net> yet. Since most mailinglists only allow postings from subscribed addresses, his message won't get through (Some, but not all mailing lists allow you to specify alternate addresses). So at the very least, any software implementing Michael's proposal needs to allow the user to override the automatic generation of new subaddresses. (This of course means user interaction and it means user errors - I know that I often make errors of that kind when I first post to a new mailinglist) > Perhaps you are unaware of the fact that email is much like a > postcard, without the stamping security measure. Anybody at any time > can read messages, or in fact modify them in every way, so long as > they are located within the relevant mail path. The honour system > is the only widespread protection in existence. That and the sheer number of mail paths. A spammer is probably not in a position where he can intercept a significant number of mails. hp -- _ | Peter J. Holzer | Je höher der Norden, desto weniger wird |_|_) | Sysadmin WSR | überhaupt gesprochen, also auch kein Dialekt. | | | hjp at hjp.at | Hallig Gröde ist fast gänzlich dialektfrei. __/ | http://www.hjp.at/ | -- Hannes Petersen in desd
Attachment:
pgpQWJW0cIzsn.pgp
Description: PGP signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg