On Thu, 2004-01-15 at 14:49, Brian Warner wrote: > Howdy all. I'm working on an anti-spam SMTP replacement called PETmail [1] > (which will be presented at CodeCon next month). I'm in the process of adding > mixminion support to it, and have a few small patches to make it easier for > my agent program to drive mixminion as a child process. The patches are > attached below. Thanks! I'm going to apply your patches, with a couple of minor style changes. They should appear in 0.0.7. > The first is just to emit the version number and testing-warning on stderr > instead of stdout, so that they are not mixed up with the SURB or decoded > message being emitted on stdout. It looks like there is a --quiet argument > intended to silence these messages, but passing that argument causes a > failure later, as it doesn't appear in any of the getopt lists. Good catch; thanks! > The second adds a --passphrase-fd option to the 'generate-surb' command, and > works just like gpg's option of the same name. This makes it possible to run > mixminion as a child process to generate a SURB, passing the keyring > passphrase in on a spare filehandle, perhaps fd 3. (PETmail will publish > these SURBs through a "Transport Server", described vaguely in the paper > referenced below, to accomplish the nymserver-like property of allowing > repeated access to the same anonymous recipient). Sounds excellent. I'll try to read the paper in the next couple of days. BTW, I assume you are aware of the potential anonymity threats associated with giving users as many SURBs as they ask for. (If the adversary has an unlimited number of SURBs for Alice, he can flood Alice to find out who she is.) I see there's something in the paper about rate limiting; It'll be interesting to see how this works. [...] > In addition, I am looking at adding something like a --surb-fd to 'mixmaster > send', which would make it possible to send messages through a SURB without > having to create a temporary file first. At the moment you can pass the > message body or the SURB in on stdin, but not both. I haven't investigated > how to actually implement this, though.. I suspect it will be trickier than > --passphrase-fd was. Actually, it wasn't very hard at all. I'll check this in too. Many thanks, -- Nick
Attachment:
signature.asc
Description: This is a digitally signed message part