Specing out the hardware
Specing out the OS
Filesystem
"uptime" considerations
To be Middle or not Middle
Should you run your remailer behind a nym?
Bandwidth considerations
Setting up obtuse smtpd to handle the load
Setting up sendmail to handle the load
Setting up postfix to handle the load
Setting up smap to handle the load
Setting up qmail to handle the load
Setting up Microsoft Exchange to handle the load
Setting up Solaris Internet Mail to handle the load
Setting up iPlanet Mail Server to handle the load
Advanced MTA configurations and tips
This document would not have been possible without all the information contributed by other people.
Principal Author: Michael T. Shinn (faq AT shinn DOT net)
Additional Authors:
trek AT trek DOT eu DOT or
cmeclax Admin (cmeclax AT ixazon DOT dynip DOT com)
christian mock (cm AT tahina DOT priv DOT at)
Editors:
Comments and revisions provided by: cmeclax Admin (cmeclax AT ixazon DOT dynip DOT com)
Peter Palfrader (peter AT palfrader DOT org)
Others that I haven't had a chance to add to these credits (but I will!)
The authors of mixmaster, nymserv, multipost, reliable, rlist, PGP,
premail, My Private Idaho, ghio, freedom and all other remailer,
mail2news, crypto and pinger software.
You will find the most recent version of this document at lexx.shinn.net/faq/.
New versions of this document will be periodically posted to the alt.privacy.anon-server newsgroup.
They will also be uploaded to various anonymous ftp sites that archive such information including ftp://ftp.shinn.net/HOWTOs.
If you make a translation of this document into another language, let me know and I'll include a reference to it here.
We rely on you, the reader, to make this FAQ useful and informative. If
you have any suggestions, corrections, or comments, please send them to
faq AT shinn DOT net and we will will try to incorporate them in the next revision.
This FAQ is free documentation; you can redistribute it and/or modify
it under the terms of the LDP license. This document is distributed in
the hope that it will be useful, but without any warranty; without even
the implied warranty of merchantability or fitness for a particular
purpose. See the LDP license for more details.
I've been the remailer operator for the GILC/GMS/EPIC remailer for five
years. I also run the shinn remailer and the Shinn.net mail2news
gateway. During that time I have learned a few lessons about what
to do and what not to do as a remailer operator. In the past, running
a remailer required a significant amount of technical knowledge.
Now, thanks to remailers like Reliable, it is becoming easier and easier
for anyone to run a remailer. This is a wonderful development, because
now we can expect there to be more and more remailers in the network, and
the more remailers we have, the more secure the network will become.
Unfortunately, there is no FAQ to explain the lessons learned and best
practices for running a remailer. It is my intention and those of
the people helping me with this FAQ, to include that information in this
document.
We could use your suggestions and ideas on how to improve this document.
Please send any questions, comments or whatnot to: admins AT mixmaster
DOT shinn DOT net.
This document was written to help you to setup and run a remailer,
mail2news gateway and/or remailer stat "pinger". It is not a document
to help you to use a remailer or mail2news gateway, although this
document should be of interest to those users. It is not designed to
answer questions about remailer or mail2news
gateway use. If you need help on how to use anonymous remailers or
mail2news gateways, then you want to read the Anonymous Remailer FAQ
Part I.
"A remailer is a computer service which privatizes your e-mail. A
remailer is in sharp contrast to the average Internet Service Providers
ISP which is terribly anti-private. In fact, ISP could equally stand
for "Internet Surveillance Point". Click here to Learn About Email Privacy.
"Traditionally, a remailer allowed you to send electronic mail to a
Usenet news group, or to a person, without revealing your true name or
e-mail address to the recipient. Today, new web-based remailers permit
you to send mail using your real name (if you wish), while protecting
your email records from the snooping eyes of your Internet Service
Provider.
"In the first version of this FAQ (published in 1995), all popular
remailers were free-of-charge. Today, a number of services either
charge user fees, or support themselves via advertisers.
an e-mail address, with the ability to "POP" the traffic down
an internet connection to and from the remailer itself that can handle the remailer traffic
a system (hardware) that can handle the traffic
UNIX users: 486 DX 33Mhz (Yes, believe it or not, a few BIG remailers run on such humble hardware, imagine that.)
Windows users: Pentium II, 200Mhz, 64MB RAM. (For OSes with significant GUI overhead
you need more RAM and more CPU power.) Comments: This is my best guess, I would be
delighted to hear from remops running remailers on Windows systems for comment. I imagine
you can run a remailer on less hardware, but I wouldn't know from first hand experience.
We're looking for minimum hardware requirements here, so think bare minimum without OS thrashing.
an OS that can handle the traffic
UNIX: Linux, BSD, Solaris, Open BSD, Free BSD are all good choices. AIX, HPUX, IRIX
would do well too, except that they are not nearly as well supported with good ports of
tools like PGP, ripem, perl, etc. If you don't mind being a "lone ranger" with those
OSes, then go for it. Otherwise, expect more problems with those OSes.
Windows: Windows NT or Windows 2000. Windows 98, 95 or ME are all well and good, but
the suffer in the reliability department, whereas NT and 2000 are signicantly more stable
than 95, 98 and even ME. They also offer more security services, ACL control and other
features needed to secure the system you are running your remailer on.
Examples:
Shell Account
Dial-up user with POP e-mail account
Also, make sure this IP address is not listed in the ORBS, RBL, RSS and other spam blacklists.
Otherwise, you will find your mail being rejected by sites you try to send messages to and possibly
from other remailers.
Dedicated, high speed internet connection (DSL, T-1, Cable modem, etc.)
Dedicated box for the remailer that does NOTHING else (no users on this box!)
In practical terms, the size of the box depends on what else, besides remailing, it will be doing. If the box is
just a remailer, then a system of lesser proportions will be needed. If the box will be also running as a mail2news
gateway, remailer and pinger, and it will have web and finger services to access the pingers data, then the ideal
hardware cases below apply. MTAs (like sendmail) are very resource hungry, so for the UNIX numbers below, the assumption
is that you will be using sendmail. qmail and other MTAs use less resources, but they are rarely installed by default
and require some effort to setup. Regardless, if you can throw more hardware at the problem, then all the better.
UNIX: Pentium Pro 200, 128MB of RAM
(Yes, this is overkill, Mikes last remailer was a P166 with 64MB of RAM and it
did pretty well being a pinger, remailer, mail2news gateway all running on sendmail, Andy's remailer is a 486, and its
running just fine - but he's using qmail, which uses less resources than sendmail. Keep in mind, this is an ideal case.)
Windows: Pentium III, 333Mhx, 256MB of RAM
(Yes, this too is probably overkill)
In either case, the most important thing is that your remailer not do anything
else unrelated to remailing. This system should not be your workstation, firewall,
game box, etc. It should be an isolated server, with NO user accounts, except for
yours (and any other admin that helps to run the remailer). It should be running
no additional services or programs except the remailer, programs that support the
remailer and programs that help to keep the box and OS secure and functioning
properly.
UNIX based OS
Commentary: Windows NT, Mac OS X, Windows 2000 and other OSes are all fine operating systems,
but they have significant overhead invested in their GUIs which are not readily
(or in the case of Mac OS X, easily) detached from their actual OS. This means
they waste alot of cycles on the GUI, instead of the remailer, which means,
everything else being equal, they will be slower and less reliable than systems
that are not wasting cycles on GUI overhead. Remember, youre remailer is a
server not a worstation, so you shouldn't be running regular applications
on it anyway. Resist the temptation to overload your remailer with "cool" things
like nifty looking GUIs. This does nothing for your users except potentially
slow the system down, and it may open up serious security holes in the remailer
itself.
If you want to use a windows based OS, then try to use Windows NT or Windows 2000, or
, if you can make it all work, Mac OS X. Which is frankly, probably not that far
away from being a UNIX OS anyway. The bottom line is to pick an OS that will be
reliable, stable and secure. And, most importantly, one that you will be able to
manage properly.
An ISP/NSP that will support and defend your remailer (ie, they won't buckle and force you to shut
down just because someone is complaining) See the section on running a remailer
behind a nym if you are really worried about this.
The hardware you need is a function of the remailer software, OS and MTA (if you have one) that
you plan to use.
For instance, an OS with a GUI running on top of it needs more CPU power and more RAM for that
GUI than an OS that can run without a GUI. Therefore, Windows OSes will need to run on faster
systems with more RAM than OSes such as Linux, BSD, etc - as they do not need GUIs to run as
remailers.
Recommended system: (See above, but to reiterate the point)
Pentium Pro 200, with 128MB of RAM running Linux or OpenBSD with two identical hard drives running
in a Raid 0 configuration. Use qmail instead of sendmail if you can. It can not be stressed enough
that the OS you use be secure, reliable and within your knowledge base. It does you no good to drop
a stock Redhat Linux on the net without adequate knowledge about how to run it and lock it down. It
will get owned, crash or both. IF you want to go the UNIX route, and you do not know UNIX, then build
yourself FreeBSD, OpenBSD or Linux box from scratch, break it a bunch of times, try to secure it
ask your evil friends to try to break into it, and learn. It will be a worthwhile experience to challenge
yourself like this, and your users will thank you for the added reliability and security that comes with
knowledge of the system you are running.
Specing out the OS
This can be a very "religious" argument for some users, but for my money, I recommend a UNIX
based OS for your OS if you know what you are doing. There are alot of things that you
can do wrong with a UNIX OS, opening the remailer up to attack, if you do not know what you
are doing. Still, its a wonderful learning experience to know how to run a BSD, Solaris,
Linux, etc. based box and these OSes provide you with an ideal platform for running a remailer.
For ease of use though, nothing beats Windows NT or 2000 and Reliable. Windows 95, 98 and even
ME are not recommened for remailer use as they are significantly less stable than NT or 2000.
But, a remailer will run just as well on 95, 98 or ME. The bottom line here is that should use
the most reliable, stable and secure OS that you can sucessful manage. It might be tempting to
use the latest gee wiz bang feature rich or "secure" OS, but if you don't know how to manage
that system, you're headed for trouble.
The size of your remailing pool with effect the amount of storage space you will need, and whether
your mail is spooling up somewhere. For instance, if you are using a redirection service (a nym, bigfoot,
a free mail service, etc.) you need to figure out the maximum size of your mailbox and how often you will
be pulling mail down from that service.
Again, the ideal way to run a remailer is with its own MTA, that way you do not run the risk of losing
mail because your ISP stopped excepting mail for you because you went over quota.
Since Type I messages can vary in size, its hard to be precise, but at
any given time, the pool can have 10-20 megs of messages waiting in the
"inbox", and your outbound spool can have 20-150 megs waiting in it if
another remailer is having problems accepting incoming mail. On really
heavy days, this can end up being hundreds of megs waiting to go out.
Hard Drives are cheap these days, so give yourself a few gigs to work
with and you should be more than safe (for now, in 5-10 years, the
requirements will no doubt be much higher with increased traffic levels
and message sizes, due to increased user bandwidth). Leave yourself
plenty of room to grow. Nothing is more frustrating than to run out
space for your mail queue. It can really ruin your day.
Moral of the story: Give yourself plenty of drive space to work with.
The size of your remailing pool with effect the amount of storage space you will need, and whether
your mail is spooling up somewhere. For instance, if you are using a redirection service (a nym, bigfoot,
a free mail service, etc.) you need to figure out the maximum size of your mailbox and how often you will
be pulling mail down from that service.
As above, the ideal way to run a remailer is with its own MTA, that way you do not run the risk of losing
mail because your ISP stopped excepting mail for you because you went over quota or they ran out of drive space(!).
Nym
mail2news gateways
Multipost
The actual code, dbs and (optional) dup/BI code takes up approx 1 MB of space, if that.
However, the logs the gateway generates take up alot of space. The backups made of
usenet posts (you can not believe all the
things that go wrong with usenet...) take up even more. The logs/backups can take up
over 30 MB in the course of 90 days at a rate of only 100 posts a day.
If you don't care about backups or logs, just redirect the files to /dev/null and be
done with it, but keeping backups is a useful way to help the maintainers of the mail2news
gateway you are using debug the code. Keep in mind that usenet posts are public.
"pinger" services
Classic
rlist
Code: 1MB of space needed.
Databases: 5MB
remlist
Code: 1MB of space needed.
Databases: 5MB
Pingstats
Experimental
Computer Cryptographys comparison stats pinger
Encrypted filesystems
UNIX
Linux
Please see the Linux Encrypted Filesystem How To. (local copy here)
FreeBSD
OpenBSD
Windows
"uptime" considerations (pick your OS, hardware, and if you are dialing up, log on times carefully)
In a nutsell, if your host is not up 24/7 recieving and sending remailer messages, you need to log on
regularly and often to recieve remailer messages so as to properly server your users and to also prevent
your POP box (if you are using one) or mail relay to fill up with mail waiting to be sent to you (and
also possibly running you over quota, causing your mail to bounce).
Minimum uptime
Try to log/POP down your mail in at regular intervals through out the day at least four times a day.
Ideal
24/7: 365 days a year, 24 hours a day on a static IP address that has its own MTA.
To be Middle or not Middle
If your ISP will not allow you to run a remailer, then consider running a "middleman". This
creates another "hop" in the remailer network, and adds much needed security to the whole
system without creating a situation where complaints will ever be directed at you. "middleman"
remailers are basically hidden remailers. End users will never see posts or e-mail coming from
them, so its much safer to run a "middleman" remailer and we need all the remailers we can get.
Its also useful, to end users, that there be middle remailers (in case
you need any further encouragement to at least setup a middle remailer)
In a nym reply block, it is good for the last remailer chain to be a
middleman. This makes the message to the user's real address come from
any of several remailers (middle remailers are not endpoint remailers.
They always send their messages thru other remailers), and it's harder
to trace. The remailer should also remix, as that way no one can trace
the message from the middleman to where it comes out.
If you can run an "end-point" remailer, that is a remailer that posts and e-mail's to end users
will come from, then do not set your remailer up as a "middle" remailer. The remailer network also
needs non-middle man remailers. Without those non-middle man remailers, the entire network would not
operate. (Its the non-middle remailers that actually send messages on to end-users and to usenet).
This is the ultimate in "hidden" remailers. If you are concerned about running a
"middle" remailer, even though you won't have to deal with posts or e-mails coming
from your remailer (which means no real need to worry about complaints), then perhaps
you should run your remailer anonymously
Types
"Classic" nym.alias.net nym "hidden" remailers
This is the most secure of the options, and you can configure the
nym account to allow you to process a normal remailers level of
traffic (nym accounts restrict the volume of traffic per day to
a particular e-mail address, but this can be overridden in most
cases).
ZKS remailers (much be LOW volume unfortunately)
Higher security than "pseudo-hidden" remailers, but low volume as
ZKS will not allow more than so many messages to go to an account
per day, but you might be able to get them to make an acception.
Thats assuming, of course, that their software makes it possible to
do this. ZKS is also really easy to setup accounts with.
Hush Mail
Secure Nym
Cotse
Pseudo-hidden remailers
This is an extermely low security option. It really doesn't hide
a remailer well.
Free POP services
Bigfoot, yahoo and other redirectors
Instructions for setting up a "Classic" nym.alias.net nym "hidden" remailer
"Arick receives ~31 MB
each day and sends ~57 MB each day on an average traffic count of
2100
messages each day, according to daily mailstats(1) output from May.
Per month, this would mean receiving ~960 MB, and sending ~1.7 GB."
Austria was then processing 2 500 to 3 000 messages per day.
Frog-Admin? also summarized the peak loads for frog and azerty
remailers:
Some remailers report daily loads in answer to a "remailer-stats"
request. This is not necessarily completely accurate; there are bugs
in Reliable. All "remailer-stats" are available from two sources:
Frog and Weasel (Peter). Frog has the original, but what you see
depends on your browser, its settings, and your aesthetic taste. Try
these URLs:
"Austria is getting some 80MB/day inbound and 60 outbound, averaged over the last two months;
there have been months with 120/100 MB. in numbers, this is about
3500 mails/day ATM, with peaks at above 5000. according to frog's
"market share" pages, austria is one of the remailers that gets most
traffic, so these are kinda maximum numbers."
Type I remailers
Number of posts per day: A large remailer, on a typical day, will do approximately
3500 posts/e-mails a day, with spikes up to 5000 or more posts/e-mails a day. (Current as of Dec 2000)
Size of typical Type I message:
Maximum size of any message coming into system: Varies depending on how you
have your remailer and/or MTA setup. A good maximum is 1024KBytes, or about
one Meg, but this is entirely dependent on what you want to allow thru your
system (binaries, or no binaries).
Type II remailers
With type II remailers, all "packets" are always 28125 bytes in size (20480 before
they become an e-mail message) and with POP/IMAP overhead, each packet can end up
being 30K. So the bandwidth needs of a Type II can and usually are higher than a typical Type I.
As with Type I remailers, the bandwidth
the remailer uses is a function of how many messages flow thru it in a given period of.
In other words, how popular it is. But, via some basic math, we can determine what the
bandwidth needs of a Typical Type II remailer, like the shinn remailer, are:
Number of posts per day: As of Dec 2000, a large remailer will do approximately 3200-4000 Type II
messages a day on average, with spikes above 5000.
Size of typical Type II packet : 20480
Size of typical Type II message (fully assembled) : 28125 or 30K if you are POPing the message
Maximum size of any message coming into system: Varies depending on how you
have your remailer and/or MTA setup. A good maximum is 1024KBytes, or about
one Meg, but this is entirely dependent on what you want to allow thru your
system (binaries, or no binaries).
This pinger needs only a Unix account with gpg, Mix 2.9, a mail server, procmail, and a random device;
it does not need a database or premail. Capstrings and keyrings are
automatically updated and (if tmpwatch is installed) expired. It generates
stats in both formats for both Mixmaster and Cypherpunk remailers (but no
nymservers yet). To get the source, send a message with subject
"get-pingstats" to . Please allow for the latency of this remailer for
delivery (it may take a day or more on a busy day).
How to just configure mix to allow from: nick names (not full from line: forging)
How to add in a disclaimer to the body of the message if allowing user defined from: lines
How to prevent any mucking around of the from lines
How to block headers
Pulling mail down via POP
Abuse complaints
There are three ways of handling them via the auto responder.
1. Have all messages to the abuse address go to an e-mail
account that some person needs to read. This can be a bit of headache
because you will see all the e-mails sent to the abuse account before
the complaintant has read your abuse auto-response. However, it also means
that you will be aware of the complainants coming into your system, which
might be helpful if you don't mind the extra e-mail, and the fact that the
people complaining will expect some kind of response from you - which means
you need to either respond, or to accept that they will be upset because you
did not respond.
2.This is the preferred method. Make sure your abuse e-mail address is
abuse@your-host.com, because thats what most users expect it to be for a system.
Setup your mix.cfg file like this:
MAILABUSE mbox.abuse
This will save all complaint e-mails to a seperate mailbox, but will not put
those messages in your real mailbox. Make sure your abuse.txt contains instructions
on what e-mail address(es) that a user can send e-mail to if they still need to
speak with a real person (and they might need to). See abuse.txt for
ideas.
3.The third option is to change mixmaster so that it doesn't send an
e-mail address in the headers as the abuse contact, but instead sends a URL to
a website that explains your abuse policy, and contains instructions on how to
contact the admin(s) of the site should they need futher assistance. To do this,
you need to:
Not finished yet, sorry
Using procmail to help with loops or junk
Procmail is far more useful than using the .forward file. It allows you to reduce on the system by
catching loops before they reach mix.
Mixmaster 2.9BetaX
Unpack the archive
Build the binaries
Configure mix.cfg
Setup your abuse.txt file
Setup your help.txt file
Sign your remailers public key
backup the mix binary to removeable media
Secure the backup of the mix binary
Sign your abuse.txt file
Sign your help.txt file
Allowing auto blocks or not?
Blocking binaries, or not?
Setup your remailing strategy
Setup your MTA
Setup your input throttling system (if any)
Setup your output throttling system (if any)
How to allow full from: line forging
How to just configure mix to allow from: nick names (not full from line: forging)
How to add in a disclaimer to the body of the message if allowing user defined from: lines
How to prevent any mucking around of the from lines
How to block headers
Pulling mail down via POP
Abuse complaints
There are three ways of handling them via the auto responder.
1. Have all messages to the abuse address go to an e-mail
account that some person needs to read. This can be a bit of headache
because you will see all the e-mails sent to the abuse account before
the complaintant has read your abuse auto-response. However, it also means
that you will be aware of the complainants coming into your system, which
might be helpful if you don't mind the extra e-mail, and the fact that the
people complaining will expect some kind of response from you - which means
you need to either respond, or to accept that they will be upset because you
did not respond.
2.This is the preferred method. Make sure your abuse e-mail address is
abuse@your-host.com, because thats what most users expect it to be for a system.
Setup your mix.cfg file like this:
MAILABUSE mbox.abuse
This will save all complaint e-mails to a seperate mailbox, but will not put
those messages in your real mailbox. Make sure your abuse.txt contains instructions
on what e-mail address(es) that a user can send e-mail to if they still need to
speak with a real person (and they might need to). See abuse.txt for
ideas.
3.The third option is to change mixmaster so that it doesn't send an
e-mail address in the headers as the abuse contact, but instead sends a URL to
a website that explains your abuse policy, and contains instructions on how to
contact the admin(s) of the site should they need futher assistance. To do this,
you need to:
Not finished yet, sorry
Using procmail to help with loops or junk
Procmail is far more useful than using the .forward file. It allows you to reduce on the system by
catching loops before they reach mix.
Freedom
ghio
Windows
Reliable
Setting up a mail2news gateway
UNIX
multipost
Setting up multipost is extremely easy.
Installation:
Change the variables inside multipost to reflect your news servers, IP address and so on.
Then, setup either your .procmailrc or .forward files to call multipost. We recommend using
.procmailrc for those systems that use procmail as their local delivery agent. (Otherwise,
add this to your .forward to call procmail:)
procmail
.forward
Windows
Getting access to news servers for posting purposes
Setting up a "pinger"
Configuring the software
rlist
Setting up premail
.remailers file
pubring.asc
Notes for PGP 6.5.x users: PGP 6.5.x requires keys to be "trusted", so you will need
to sign the keys of all the remailers you intend to ping with a trusted key, or premail
will choke and not encrypt or send messages to that remailer.
Adding Type I remailers:
rlist -add remailer_name
Adding Type II remailers:
rlist -add \(remailer_name\)
Remember to use the escaped "()"s. premail uses those symbols to tell it that the remailer is
a Type II (mix) remailer.
Setting up the cronjob
The scripts getkeys, putkeys, mixping, gpgping,
and putpings are run at regular intervals.
Making the service available to users
finger
UNIX
You can run finger out of inetd, but it is not recommened. inetd has resource management
problems. Our best advice is to use tcpserver (Thanks go to Andy Dustman for introducing
us to this great tool). Available from: http://cr.yp.to/ucspi-tcp.html
If you are running finger without a nym server, then setup finger this way:
In either case, this will launch nymserv in a chroot "jail" running as the nymuser. You will need to adjust
the paths and username above accordingly for your system as you have setup nymserv.
nymserv will not work inside the chroot jail until you install a few things there.
Instructions for creating the chroot jail:
If you can not figure out what libraries a particular program will need, and you can not
compile the program statically, then use ldd to list the libraries the program will
need. For example:
Files to copy into usr/lib/
cp -r /usr/lib/perl5 .
Files to copy into lib/
Files to copy into usr/
Windows
Getting a finger server and client
Setting it up
http
On your own box
As with any service, if you are going to run this on your own boxes, you need,
ideally, a static IP address and DNS name resolution services. Less ideal is
a dynamic DNS service that will adjust your FQDN to your current IP address. This
less desirable because there will be some latency in the time your IP address
changes, the time in which your DNS record changes and the time in which it takes
your DNS record to age out of any users DNS.
Dynamic DNS services
UNIX
Windows
Redirector services
List of services
Tools to help push your cotent to these services automagically
UNIX
Windows
regular posts to usenet
UNIX
Setting up the cronjob
Scripts
Windows
Setting up the AT job
Scripts
e-mail
UNIX
rlist
remlist
pingstats
This method uses procmail and is provided by the cmeclax remailer op. Put
this procmail recipe in the .procmailrc file for your pinger user.
:0 h
# Take just the headers and discard the body.
*
Subject: keh'umri- sidju
# Match the subject. "h'" matches either "h" or "'".
* !
FROM_DAEMON
# If it's a MAILER-DAEMON message, bypass this rule.
# The X-Loop: criterion in the procmail recipe needs to match the address in the
# X-Loop: header it adds.
* !
X-Loop: YOUR_ADDRESS
| (formail -rtb -I "Precedence: junk" \
# Formail is a program which takes a message and prepares a reply.
-I "From: " \
-I "Subject: pilno le cmevi'u ke'umri segau makau" \
-A "X-Loop: "; \
# The message has only one subject, but it can have several X-Loop: headers.
cat $HOME/Mix/help-lojban.txt ) | $SENDMAIL -oi -t
# What -oi is supposed to mean, I don't know. It isn't in the man page.
:0 h
*
You can improve security installing an encryption layer at SMTP level with
Transport Layer Security -Secure Sockets Layer as described in theRFC 2487. You can also make server and client authentication via certificates. Other remailers can open and receive connections to/from yuor box totally encrypted (headers and body message) and authenticated in a secure way (like https protocol). Users can make the same thing also using some browser (Netscape 4.5+, Microsoft Outlook 5+).
Setting up with postfix
Install the Postfix/TLS by Lutz J\xe4nicke (Lutz DOT Jaenicke AT aet DOT TU-Cottbus DOT DE).
Setting up with qmail Install the tls.patch by Frederik Vermeulen (jos-tls AT kotnet DOT org). Extract your certificate using openssl package:
openssl x509 -text < /var/qmail/control/cert.pem
Setting up with sendmail Install the 8.11+ release that include TLS support.
Setting up with ZMailer Install the 2.99.51+ release that include TLS support.
After enabling TLS in your SMTP server please download remailers certificates and send yours to remailer-admin AT riot DOT eu DOT org.
It blocks mail from RBL-listed sites. It works with any SMTP server that can run undertcpserver. You must install theRSS patch in order to work with all the lists and not only MAPS RBL. You must also make your service avaiable from remailers blocked by some lists (ex.: ORBS for lefarris, DUL for dial-up remailers) simply with tcpserver.
spammers. Normally only spam is sent through these. The domain is rbl.maps.vix.com.
MAPS RSS (Relay Spam Stopper) for known
spam-relaying mail servers. Normally open relays begin used from spammers. The domain is relays.mail-abuse.org.
ORBS (Open Relay Behaviour-modification System)
for known (tested) open relaying mail servers. Some of these are not used by spammers and could be used as a proxy (optionally encrypted by TLS). The domain is relays.orbs.org.
MAPS DUL (Dial-Up List) for IPs reserved to
dial-up lines. The MAPS TSI encourage its use, but many legitimate users and some remailer will be stopped and the privacy is, in some parts, violated . The domain is dul.mail-abuse.org.
teergrube
German for tar-pit. This is a SMTP layer replacement for your
MTA in daemon mode. It slows down flooders and spammers by
keeping the SMTP session open, but grinding progress on the
session to a halt, essentially putting the spammer or flooder
out of business and denying them their tools (their box is all
locked up trying to talk to your box).
There are several teergrubes out there, but this is the only
one we could find that is being actively maintained:
Note: I'm going to pull this out and make it into its own
FAQ (and link to it from the RemOp? faq) eventually, since its clearly
applicable outside of the world of remailing, and this section to fill
several FAQs all by itself.
How to think about security
Security is not about software, patches or products. Its a process. Apply the process
correctly, and you can reduce and manage your risk. Don't apply the process, and you're
doomed.
A Process based approach This process is based on several years of experience with both public and private sector infosec.
It is a best practice document written to reduce all that has been written about this topic to
what we believe is a very common sense and easy to practice process. For more information, please
see The Shadow Group's website.
The Process steps
Analyze
Reduce to policies
Secure/Implement
Monitor
Test
Improve
Repeat
Analyze
Quanitifying value Attack Tree Analysis
Reduce to policies
Secure/Implement
OS specific techniques
UNIX
Locking the box down from remote attacks
Firewalling
shutting down unnecessary processes/services
Locking the box down from local attacks
ID&R
Windows
Locking the box down from remote attacks
Firewalling
shutting down unnecessary processes/services
Turning off shares
Locking the box down from local attacks
Protecting your box from trojans and viruses
Turning off unnecessary processes
patching
ID&R
Securing your network
ID&R
Router filters
Firewalling
Packet based firewalls
Application based proxies
Hybrids
The Importance of protecting keys
Monitor
IDS&R
Log auditing
Human factors
Test
SPA
Improve
Find it. Fix it.
Tools to help automate the patching process
Repeat
Final Words
Did we mention the importance of applying the process above honestly, completely and regularly?
Nothing you do will be more important than actually applying this process. It puts you in the right
frame of mind to think about security, and it will keep you from having to pay for your mistakes
in the long run.
Do not keep logs. More specifically: Dont keep logs of
inbound and
outbound messages, SMTP connections or ICMP traffic, or any other time
stamps that would be useful in determining when messages enter or leave
your remailer. If you need to keep logs for a short period of time, perhaps
to be used to help throttle
Created by: mshinn .
Last Modification: Friday 11 of February, 2005 10:16:04 EST by mshinn .
The content on this page is licensed under the terms of the Got Root License.
Contact us 
Wiki
.
Last Modification: Friday 11 of February, 2005 10:16:04 EST by 
