There's an admixture of procmail + sendmail + DNS stuff in this reply - the
basics are handled by procmail, but there are some additional methods
(involving sendmail/DNS) offered to improve the anonymity of the account -
mostly baffles for people who would spoof your server to attempt an ID of
the user account (something I do all the time when tracking down user
identifies of people being a pain). I'm just a casual user of these tools
- certaintly not a pro with them, and these merely represent how *I'd*
approach the problem.
At 12:02 PM 6/9/97 -0500, Phong Ta wrote:
I am trying to setup an anonymous user who has a return email
address looks something like: trwe(_at_)bogus(_dot_)com
Are you attempting to set up an anonymous REMAILER account for this user
(that is, mail to that account forwards to a real account for them, and
they can also send messages to an address on your system which in turn
strips identifying info from their message and sends it back out)?
If so, read on. If no, well, I can't personally see why anybody would have
a legitamate need to send a completely anonymous post without any ability
of the recipient to send a reply - that would appear to have too much
application in harrasment and spamming (though the ISP offering the
anonymity services will bear the brunt of the consumers retaliation from
this). Concealing the identity of the sender while still allowing replies
is okay.
One question comes to mind though: why not direct them to one of the many
anonimizers already on the net? That would keep you from having to deal
with implementation details.
Anyway...
bogus.com (or whatever) needs to be a real domain, and your mail server
needs to be the mail exchange for it. Also note that you want to ensure
that the user's info (real name, etc) doesn't appear in the password file
("account database"), since it is trivial to perform a VRFY of the address
on the SMTP server, and in most cases, this'll belt back the username.
Note that if bogus.com is a domain _registered_to_the_user_, you have a big
chink in your anonymity armour.
As long as incoming mail doesn't need to be double-blinded (double blinding
is used by the typical anonymous remailer host to conceal the identity of
ALL parties), then you could set up a simple mail alias for them (see the
sendmail aliases file) - incoming address maps to an outgoing address
(which could be on another system).
However, since many local users can view that file (and SMTP VRFY can
expose the address alias here as well), you should probably instead
implement it as a forward inside of procmail:
(at the bottom of the procmail for that user):
:0
* LASTFOLDER ?? ^^^^
! users_real_address(_at_)domain(_dot_)com
(this says if the message hasn't already been stored in a folder due to
recipes executed earlier in the script, then send the mail along to the
user). This should do the trick (seems to be working fine for me ever
since someone provided it to me).
Now, as for outgoing email, the user could mail THEMSELVES (at this anon
address) with additional headers in their message, or some lines at the top
of their message body:
ANON-To: (addresses)
ANON-Cc: (addresses)
ANON-Bcc: (addresses)
ANON-Pass: (password, for security, so people don't forge from the account.
Should be a keyword of some sort, BUT NOT THE ACCOUNT PASSWORD, as it
traverses the net between the user and your system as cleartext)
(header/field names arbitrarily chosen. If headers, I strongly suggest
prefixing them with "X-")
Then at the top of your script, you would check to see if the header/body
(as appropriate) contained these headers, and if so, would construct a new
outgoing message from them, containing just the body (minus these fields if
they're at the top of the body) & subject of the original message, and pass
that through sendmail. You'll make much use of formail here.
Non-trivial, but not all that difficult if you put your mind to it. I
don't have a script to do this, nor the time to write and debug one, but
this information should get you running in one of the right directions.
sendmail alias would do some of the tricks but the anonymous
user will need to have a shell account to send out mail.
However, it doesn't mean that they have to have login privledges to it if
YOU maintain the scripts yourself. And if it is forwarding incoming mail
to a _real_ address, then they don't need to access a POP mailbox or
anything - they have no need for the account password at all then. That
would make for a _fairly_ secure (esp if you set the passwords file up to
disallow password access to the account) and low-overhead shell account.
If you are sysadm (as I presume you are), then you could set up
virtualusertable in sendmail (v8 supports it), and a subdomain in the DNS
as follows:
anon. A 127.0.0.1
MX 0 "realmailhost.com."
Then all the anon accounts could be virtualized through the
virtualusertable database. This does a few extra things for you: clearly
identifies anon accounts as such (if you want to do such a thing, perhaps
you don't), adds another level of userid dereferencing (if someone simply
telnets to port 25 (SMTP - to attempt a VRFY) on the anon subdomain, it'll
attempt to connect them to their own system - where they are unlikely to
find much info about your user (although if they're ON the same system as
your mailserver, that's another story - you could point it at an invalid
IP, or to a different mail server from the one handling your anon accounts
to baffle these attempts). The MX record will ensure that mail sent there
will be routed along to the actual server -- anyone examining your DNS will
find this, but it's an extra step, and many won't take the effort.
One of the procmail receipt I'd used:
* !^FROM_DAEMON
| formail -trI"From: trew(_at_)bogus(_dot_)com" \
| $SENDMAIL -oi -t
The -r option to formail is generating a REPLY header and should be tossing
out all the original header fields (unless I'm mistaken, this would include
things like TO, BCC, etc). Unless I missed something early on with
formail, REPLY means it should be sending the message to the person who
sent it TO your script -- wouldn't this be the user wishing anonymity?.
Doesn't seem very useful this way - they anonimize posts to themselves.
There are some other switches which should be necessary there, '-b' would
be one (don't you want to keep the BODY of the message?).
---
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395