need someone to sell me their mail server for OpenBSD
Eric Berthiaume
to convince me to stick with one mail server and not another.
The most popular ones i've heard about for OBSD:
sendmail
qmail
postfix (using it at work ... on solaris)
of course if there is others feel free to include them.
This would be for my home network which consist of a OBSD box
(firewall,NAT,DHCPD,Web) and some windows clients.
My requirements are:
- main goal is to keep all my mail accounts in one place.
- smtp.
- imap (secure imap would be nice ... stunnel?)
- would like that the box pulls the mails from an external account
(fetchmail?)
- would like the setup to be secure .. of course.
I'm fairly new to implenting such a setup so Documents, links and of
course feedback from OBSD users that already have this kind of setup
would be nice.
Also if anybody has some views on using "the imap part" on a firewall I
would like their two cents.
Thanks!
Eric Berthiaume
mave...@up2.com
Eric Berthiaume
ones I use (BTW Building Linux and OpenBSD firewall is reallyy a good
book for starters).
The secure imap part was only for the connection between my mail server
and my windows client.
I'm aware that from my ISP's mail server to my mail server everything is
in the clear.
One thing I haven't mention is .. what if I want to connect from a
client outside my private network to my mail server using secure imap ??
normally I should only have to open inbound connections to port 993 ??
security wise is it the same ? is most security hole found in mail
packages all concern SMTP ??
I was thinking about using sendmail but i've heard that its a pain to
configure ;)
Thanks.
Eric Berthiaume
mave...@up2.com
-----Original Message-----
Sent: December 27, 2000 5:21 PM
Subject: Re: need someone to sell me their mail server for OpenBSD
On Wed, Dec 27, 2000 at 04:27:22PM -0500, Eric Berthiaume wrote:
> The most popular ones i've heard about for OBSD:
>
> sendmail
> qmail
> postfix (using it at work ... on solaris)
>
> This would be for my home network which consist of a OBSD box
> (firewall,NAT,DHCPD,Web) and some windows clients.
>
> - main goal is to keep all my mail accounts in one place.
> - smtp.
> - imap (secure imap would be nice ... stunnel?)
> - would like that the box pulls the mails from an external account
> (fetchmail?)
> - would like the setup to be secure .. of course.
If you want to use fetchmail then you don't need external SMTP access.
You
can close off the ports sendmail uses and sending/receiving mail will
still
work. I block all incoming connections to ports 25 and 587 and my mail
works
fine.
This means that a "secure" mail program isn't all that important. No one
from the outside will be making direct connections to
sendmail/qmail/postfix
anyway. I'd still use sendmail. There have been a lot of bugs in the
past
due to its long history, but see how many bugs qmail/postfix have when
they
have been around a decade or so. Additionally, the in-tree sendmail is
audited for security issues by the OpenBSD team. The other two aren't.
As for IMAP, fetchmail can do secure IMAP if the mail server you are
connecting to supports it.
Just my $.02
Let me know if you need help with firewall rules or anything.
Henning Brauer
Check "life with qmail" at www.lifewithqmail.org - excellent reference.
Courier is easy, all needed documentation included.
Am Mittwoch, 27. Dezember 2000 22:27 schrieb Eric Berthiaume:
> Been browsing the archives and google all day but couldn't find anything
> to convince me to stick with one mail server and not another.
>
> The most popular ones i've heard about for OBSD:
>
> sendmail
> qmail
> postfix (using it at work ... on solaris)
>
[...]
--
Henning Brauer | BS Web Services
Hostmaster BSWS | Roedingsmarkt 14
hostm...@bsws.de | 20459 Hamburg
www.bsws.de | Germany
Henning Brauer
> (BTW Building Linux and OpenBSD firewall is reallyy a good
> book for starters).
Oh please be carefull - there's lots of nonsens in this book, opening serious
security holes.
> One thing I haven't mention is .. what if I want to connect from a
> client outside my private network to my mail server using secure imap ??
> normally I should only have to open inbound connections to port 993 ??
yep.
> security wise is it the same ? is most security hole found in mail
> packages all concern SMTP ??
hmm... show me an security hole in qmail-smtpd...
> I was thinking about using sendmail but i've heard that its a pain to
> configure ;)
and a security nightmare. OpenBSD's security auditing fixed a _lot_, but
there are better alternatives with cleaner designs out.
> I'd still use sendmail. There have been a lot of bugs in the
> past due to its long history,
no, due to its horrible complex design.
> but see how many bugs qmail/postfix have when they
> have been around a decade or so.
for qmail: zero?
qmail-1.03.tar.gz is from 1998 - show me only one bug.
http://cr.yp.to/maildisasters.html is _really_ worth reading.
> Additionally, the in-tree sendmail is
> audited for security issues by the OpenBSD team. The other two aren't.
qmail is written by Dan Bernstein...
qmail-smtpd has only 1121 lines of clear and easy to understand C-Code (in
the version from qmail-ldap, maybe the original has less).
Ro...@ngxweb.com
>Am Donnerstag, 28. Dezember 2000 00:44 schrieb Eric Berthiaume:
> > (BTW Building Linux and OpenBSD firewall is reallyy a good
> > book for starters).
>
>Oh please be carefull - there's lots of nonsens in this book, opening serious
>security holes.
Will you please be more specific? I, too, am using this book to build my
firewall/router (I am a unix newbie) and would like to know what kinds of
holes are opened up.
Thanks
RS
Eric Berthiaume
Am Donnerstag, 28. Dezember 2000 00:44 schrieb Eric Berthiaume:
> (BTW Building Linux and OpenBSD firewall is reallyy a good
> book for starters).
>>Oh please be carefull - there's lots of nonsens in this book, opening
serious
>>security holes.
I don't know that much in networking and in security in general to say
that this book is total crap or not but what I do know is that its THE
only book referenced as an openbsd specific on www.openbsd.com.
Would you agree that it would not be good publicity for an OS thats goal
is security to have a book that opens up security holes?
Do have any books,links,documents that might be more accurate ..
security wise ?
Thanks
Eric Berthiaume
mave...@up2.com
Henning Brauer
It's some time ago i read it and there were some parts i really got angry
about, but i can't remember completely.
I remember they told you not to filter outgoing traffic...
>
> Thanks
>
> RS
Henning Brauer
> Thanks for the tips ... i'll look closely at qmail for my needs.
> I don't know that much in networking and in security in general to say
> that this book is total crap or not but what I do know is that its THE
> only book referenced as an openbsd specific on www.openbsd.com.
I did not say it's total crap.
The first thing coming to my mind I've written in my previous mail, they tell
you not to filter outgoing traffic - a nightmare.
The second thing: they are telling you something like "you don't need to know
more about your firewall's operating system and networking than bla bla bla"
- do _never_ run a mission critical system and never never never a firewall
on an operating system you do not understand, you haven't used before. And be
sure you _understand_ TCP/IP. It might be ok for a home network to do so, but
they explicitely talk about companies networks. In this case a security
consultant is the better (and in long terms cheaper) alternative.
> Would you agree that it would not be good publicity for an OS thats goal
> is security to have a book that opens up security holes?
yep. But maybe I'm just to paranoid? I have _many_ attacks here... (and not a
single one succeded) - this could have clouded my view.
> Do have any books,links,documents that might be more accurate ..
> security wise ?
puhhh... the best is to learn from practice, what opens up the
chicken-and-egg problem...
This answer is not really sufficient - it's always easier to grumble than
making things better, unfortunately :-((
> Thanks
>
> Eric Berthiaume
> mave...@up2.com
Eric Berthiaume
angry
>about, but i can't remember completely.
>I remember they told you not to filter outgoing traffic...
Of course if your using ipf on a corporate firewall then you should
always filter outgoing traffic but i'm the only one behind the firewall
so I think its safe to say that there is no need to filter it.
You scared me for a moment (seems i'm not the only one) I really thought
you where talking about security issues in the design of ipf itself or
that the authors really didn't know how to setup rules (true the
outgoing thing is not a good practice).
Thanks for the reply.
Eric Berthiaume
mave...@up2.com
George Lewis
seriously consider it anyway. Think about what happens if you happen to get
hacked, and once they are inside, they can do whatever they like... if you
have no internal alarms setup. If they bypass your external locks and alarms,
they are free to do whatever from then on. Of course, this may all depend on
how seriously you want to take it.
George
--
George Lewis
http://schvin.net/
Eric Berthiaume
The first thing coming to my mind I've written in my previous mail, they
tell
you not to filter outgoing traffic - a nightmare.
>> probally true .. maybe i'm not enuf security minded in regards to
outgoing traffic .. maybe i'm to gullable and think that inside people
are ok ... maybe i'll change after I need to reinstall an OS on a sunday
night at 3am :)
The second thing: they are telling you something like "you don't need to
know
more about your firewall's operating system and networking than bla bla
bla"
- do _never_ run a mission critical system and never never never a
firewall
on an operating system you do not understand, you haven't used before.
>> Very true, I didn't make a case of that remark from the authors but
your totally right on this. I think the tried to make the book idiot
proof. I was a little shocked when I say the VI tutorial "Gee i'm not
that newbie".
>> I always thought that Security is a serious thing and that you should
improvise yourself security expert, even less in a corporate
environement.
But maybe I'm just to paranoid?
>> Humm not at all I encountered a sysadmin that had is personnal
cookbook on securing a solaris box directly on the net.
- Solaris 2.6 Core install + remove all yp
- No perl
- No sudo
- Everything on the machine root owned
- No users
- Signing all executables
- etc
He was doing security for a bank or something and never ran a web server
in production in is life :)
Thanks!
Eric Berthiaume
mave...@up2.com
Eric Berthiaume
and you are probally right on this.
I guess its habits like this that forge a good security person.
What would you recommend has a basic ruleset for outbound traffic?
Hey if I need to put another hard disk in my box, cause I need to log
everything, i'll do it.
I'm a junior sysadmin in an hosting comp and I think that tips like this
are more then welcomed.
I've start to play with OpenBSD primarly because of the security focus.
Thanks!
Eric Berthiaume
mave...@up2.com
-----Original Message-----
Sent: December 27, 2000 8:58 PM
Subject: Re: need someone to sell me their mail server for OpenBSD
Chuck
so that other machines that speak it will encrypt the SMTP
conneciton. Use the mc files (/usr/share/sendmail/cf/openbsd-proto.mc)
not the cf files for changes. The cf files should be treated
as binaries.
Lots of info at sendmail.org and .net. Runs around 70% of the
Internet facing mail servers.
Imap and stunnel are fine. Fetchmail is useful.
I like cyrus imap and another commercial one, there
are others.
Toni Mueller
Hello,
On Wed, Dec 27, 2000 at 04:27:22PM -0500, Eric Berthiaume wrote:
> sendmail
> qmail
> postfix (using it at work ... on solaris)
we like qmail a lot, but it still has some problems left/features
missing. You may want to look at www.qmail.org to get an idea.
> - would like that the box pulls the mails from an external account
> (fetchmail?)
fetchmail is a can of worms, imho. Especially together with your
local MTA and IP based relay control you might suddenly find
yourself happily relaying everything... Also, fetchmail doesn't
interact too well with dial on demand, imho (what do you have?).
Best Regards,
--Toni++
Al Lipscomb
> What would you recommend has a basic ruleset for outbound traffic?
>
>
a lot of trojans/spyware. It will also reduce the chances of some hacks
working.
--
|
The Libertarian Party does not have the answers to all of your problems...
But they are at least honest enough to say so.
AA4YU http://www.beekeeper.org http://www.q7.net
Henning Brauer
> I'm starting to learn the ropes of computer, network, firewall security
> and you are probally right on this.
>
> I guess its habits like this that forge a good security person.
>
> What would you recommend has a basic ruleset for outbound traffic?
In general: the same scheme as for inbound traffic. Deny all and open up
selectively.
> Hey if I need to put another hard disk in my box, cause I need to log
> everything, i'll do it.
I prefer logging out of band, dup-to is you friend ;-))
Also syslogs should be send to your logging server (you have one, haven't
you?), but you should write them local too.
> I'm a junior sysadmin in an hosting comp and I think that tips like this
> are more then welcomed.
>
> I've start to play with OpenBSD primarly because of the security focus.
for me there was a second aspect: linux' horrible behaviour under DoS...
> Thanks!
dreamwvr
hi ,
really like postfix as it is very much like sendmail without the
fun with macros..:-)) very easy to setup, manage, and well try
it you will like it.. do like djb stuff as well but never felt quite as
comfortable from a admining point of view with qmail as i did with
postfix.. YMMV .. do one that 'you' feel comfortable with at the
end of the day you will need to support it;-))
Regards - drea...@dreamwvr.com
Michael Stella
> we like qmail a lot, but it still has some problems left/features
> missing. You may want to look at www.qmail.org to get an idea.
I'm curious as to what you think is missing in qmail.
Personally, I use qmail with the LDAP and SPAMCONTROL patches,
Courier-IMAP/POP (in SSL mode), and ezmlm.
> fetchmail is a can of worms, imho. Especially together with your
> local MTA and IP based relay control you might suddenly find
> yourself happily relaying everything... Also, fetchmail doesn't
> interact too well with dial on demand, imho (what do you have?).
Fetchmail works great with dial on demand. You put 'fetchmail -q' in your
ip-down script, and 'fetchmail -d <time>' in your ip-up script. Easy.
--
Michael Stella mySEASONS.com
Sr. Unix Administrator http://www.myseasons.com
860-395-1732 x110
Knowledge is power. Power corrupts. Study hard. Be Evil. - Thyra
Toni Mueller
Hello,
On Thu, Dec 28, 2000 at 10:20:03AM -0500, Michael Stella wrote:
> On Thu, Dec 28, 2000 at 12:42:50, Toni Mueller said...
> > we like qmail a lot, but it still has some problems left/features
> > missing. You may want to look at www.qmail.org to get an idea.
> I'm curious as to what you think is missing in qmail.
since there were several questions of this kind, I think I should
post a public reply.
> Personally, I use qmail with the LDAP and SPAMCONTROL patches,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This illustrates parts of it. Most people I know of don't go
with the stock qmail but apply a set of patches. This, in turn,
is not exactly for beginners.
Taken from a different answer:
--- me:
well, first I find that there is a number of patches missing in the
std qmail distro, at least big-dns and big-todo, and also, for the
"casual" Linux user, dirsync. Then there are a number of features
missing, imho. Like early denying of mail that should be denied
by policy. Can't remember properly, but afaik qmail currently
first swallows a message, then decides to not relay it, then
trying to bounce it instead of telling the offender that it won't
relay the message in the beginning and not accept it in the first
place. Another feature much wanted everywhere is more flexibility,
eg. a std ldap connector or a hook to stuff a virus scanner in, or
so. People have been ingenious to add all sorts of stuff to qmail,
but it requires more or less handwork and is far less ready
out-of-the-box than is eg. exim or zmailer, or even a recent
sendmail. Also, to really use qmail you're well advised to also
take a look at the other stuff DJB publishes. Unfortunately the
install docs in qmail (and also the license) don't permit building
packages that install "all the good stuff", but describe how to
cling to rather ancient, inflexible and also less stable setups,
and enforce them (with "sendmail compatibility" as a named goal
I actually don't have for years now).
Last but not least qmail and most of the other DJB stuff has
really weird licensing. Fixing this up and placing it all under
BSD or GPL would be A GOOD THING, imho. Currently you find a
lot of useful bits and pieces at his site, but almost every
piece of it has a different license, sometimes even varying
from release to release... :(
That notwithstanding we use qmail almost exclusively, but also
do look into zmailer which looks very interesting, too...
----- clip
This licensing stuff imho prevents widespread commercial
adoption of qmail and drives people to postfix instead.
No vendor I talked to wants to risk anything here, or
even rely on the health or preferences of DJB, to begin with.
[side note] A license that insists on an inetd based
install with sendmail utmost compatibility (dotforward etc)
imho waives most of the real benefits and power of qmail.
I do understand, however, that this mainly is a side effect
of DJB wanting to avoid being tied up in support issues.
> > fetchmail is a can of worms, imho. Especially together with your
> > local MTA and IP based relay control you might suddenly find
> > yourself happily relaying everything... Also, fetchmail doesn't
> > interact too well with dial on demand, imho (what do you have?).
>
> Fetchmail works great with dial on demand. You put 'fetchmail -q' in your
> ip-down script, and 'fetchmail -d <time>' in your ip-up script. Easy.
Well, this only works if you have:
- your timeout is large enough so the link doesn't go down while
fetching mail
- a PPP link from the same box that fetchmail is running on
It doesn't work well, however, if you run fetchmail on one box
and a dial-on-demand ISDN router across your Ethernet, for
example. You also don't want to run fetchmail every few minutes
the line goes up or down in such an environment even if you
could start it on every line-up if you have a few dozen users
(but not enough brains or money to get a _real_ Internet
connection).
Also, if you use fetchmail and stuff the mail into localhost:smtp,
you defeat your average IP based relay control in qmail...
Best Regards,
--Toni++
Jim Breton
> This illustrates parts of it. Most people I know of don't go
> with the stock qmail but apply a set of patches. This, in turn,
> is not exactly for beginners.
True it's not for "beginners" but one could argue that taking on the
responsibility of setting up and feeding a mail server could involve a
useful learning curve, which includes applying patches.
It's really just a matter of taste though. Personally I do see the
importance in NOT including all this stuff in the stock qmail
distribution, because qmail was designed very specifically targeting
security; adding features not critical to a basic MTA introduces bloat
for people who do not need these features.
That being said, in my setup I used stock qmail for a long time; more
recently however I have applied TLS, mail-from checking (ensure that an
envelope sender's domain is valid via DNS), and support for the SMTP
SIZE command, via patches. (If anybody wants a merge of these 3 patches
let me know, I made a diff after I did some of the patchwork by hand).
> Like early denying of mail that should be denied
> by policy. Can't remember properly, but afaik qmail currently
> first swallows a message, then decides to not relay it, then
> trying to bounce it instead of telling the offender that it won't
> relay the message in the beginning and not accept it in the first
> place.
Almost - actually, it behaves this way with unknown recipient usernames;
iow, it prevents spammers/attackers from hammering your daemon with RCPT TOs
to find out what usernames exist on your machine. This is a feature. :)
Blocked relays otoh are handled immediately, the smtp client receives a
permanent error from the qmail smtp daemon.
This is getting somewhat OT but just wanted to clarify some stuff. HTH!
Toni Mueller
Hello,
On Thu, Dec 28, 2000 at 07:11:36PM +0000, Jim Breton wrote:
> On Thu, Dec 28, 2000 at 06:58:41PM +0100, Toni Mueller wrote:
> > This illustrates parts of it. Most people I know of don't go
> > with the stock qmail but apply a set of patches. This, in turn,
> > is not exactly for beginners.
> True it's not for "beginners" but one could argue that taking on the
> responsibility of setting up and feeding a mail server could involve a
> useful learning curve, which includes applying patches.
you are theoretically right, but practically wrong, imho. The question
is simiar to: "Do you want a random user to set up Linux (or even
M$ stuff) because it's (sort of) easy, or would you prefer they
started out installing OpenBSD because this is generally safer,
thus making the Internet a better place even without knowing?"
Imho neither running OpenBSD nor running qmail should be restricted
to a few enlightened people. This is not a religion, or so I hope.
Changing horses in the middle of the game needs to be fueled by
significant pain, usually.
> It's really just a matter of taste though. Personally I do see the
> importance in NOT including all this stuff in the stock qmail
> distribution, because qmail was designed very specifically targeting
Ok, this is very right in one respect (and that's probably why rblsmtpd
is in daemontools instead), but there is no "approved" or even
"coordinated" set of patches. Some patches don't work together with
some other patches. I don't have all, but only some 10 patches or
so floating around here and started to try to make this all into a
CVS tree, but this isn't completed yet.
> security; adding features not critical to a basic MTA introduces bloat
> for people who do not need these features.
But there is no way to add these features in a clean manner. Everyone
hacks away as best as he can.
> That being said, in my setup I used stock qmail for a long time; more
Well, so you didn't need to run qmail under Linux and/or wanted to
apply one or other interoperability or reliability patch (albeit
needed only in rare occasions)?
> recently however I have applied TLS, mail-from checking (ensure that an
> envelope sender's domain is valid via DNS), and support for the SMTP
> SIZE command, via patches. (If anybody wants a merge of these 3 patches
> let me know, I made a diff after I did some of the patchwork by hand).
Here a public CVS repository would help, but this is illegal under
the current licensing as far as my reading of it goes.
> iow, it prevents spammers/attackers from hammering your daemon with RCPT TOs
> to find out what usernames exist on your machine. This is a feature. :)
No. If there is really an attack going on, or address checking, then
having a valid reply address to receive the bounce on would do just
as well, only for a multiple of the message size in traffic you and I
have to pay for. The same problem could be reduced if there was a
detector program that could remember the amount of "false" connections
from a given IP # and prevent these after crossing a threshold, giving
an alarm, too.
Yes. This is highly off topic and really belongs on the qmail list
instead. But I felt to answer there where I'm asked...
Best Regards,
--Toni++
Henning Brauer
> you are theoretically right, but practically wrong, imho. The question
> is simiar to: "Do you want a random user to set up Linux (or even
> M$ stuff) because it's (sort of) easy, or would you prefer they
> started out installing OpenBSD because this is generally safer,
> thus making the Internet a better place even without knowing?"
> Imho neither running OpenBSD nor running qmail should be restricted
> to a few enlightened people. This is not a religion, or so I hope.
Users (or better Admins) without _good_ knowlegde about smtp and mail servers
AND the underlaying operating system shouldn't run mail servers, IMHO.
Running a secure and powerfull mail server is much more complicated than a
webserver or such stuff...
> Ok, this is very right in one respect (and that's probably why rblsmtpd
> is in daemontools instead), but there is no "approved" or even
> "coordinated" set of patches. Some patches don't work together with
> some other patches. I don't have all, but only some 10 patches or
> so floating around here and started to try to make this all into a
> CVS tree, but this isn't completed yet.
Have a look at qmail-ldap, there are lots of patches for ISP operation
included.
> > security; adding features not critical to a basic MTA introduces bloat
> > for people who do not need these features.
> But there is no way to add these features in a clean manner. Everyone
> hacks away as best as he can.
And therfore learns a lot about mail server operation - maybe it isn't that
bad...
> > That being said, in my setup I used stock qmail for a long time; more
> Well, so you didn't need to run qmail under Linux and/or wanted to
> apply one or other interoperability or reliability patch (albeit
> needed only in rare occasions)?
only needed because some sites don't care about RFCs, unfortunately.
I found Linux to to be a good choice for a mailserver, but this is another
discussion.
> > recently however I have applied TLS, mail-from checking (ensure that an
> > envelope sender's domain is valid via DNS), and support for the SMTP
> > SIZE command, via patches. (If anybody wants a merge of these 3 patches
> > let me know, I made a diff after I did some of the patchwork by hand).
> Here a public CVS repository would help, but this is illegal under
> the current licensing as far as my reading of it goes.
Yes, the licensing is a pain.
A central CVS tree of patches would be a good thing.
> > iow, it prevents spammers/attackers from hammering your daemon with RCPT
> > TOs to find out what usernames exist on your machine. This is a feature.
> > :)
> No. If there is really an attack going on, or address checking, then
> having a valid reply address to receive the bounce on would do just
> as well, only for a multiple of the message size in traffic you and I
> have to pay for.
qmails approch slows down this "find a valid address"-hack a _lot_ and makes
it harder (but not impossible) to automate - IMHO worth the traffic.
> The same problem could be reduced if there was a
> detector program that could remember the amount of "false" connections
> from a given IP # and prevent these after crossing a threshold, giving
> an alarm, too.
Other approch, makes sense additionally.
greetings
Henning
Jim Breton
> > That being said, in my setup I used stock qmail for a long time; more
>
> Well, so you didn't need to run qmail under Linux and/or wanted to
> apply one or other interoperability or reliability patch (albeit
> needed only in rare occasions)?
I see Henning has already responded to your message, but I didn't quite
understand what you meant by this part.
Fyi, most of the time I have been running qmail, it _was_ on Linux, and
in fact I now maintain 2 Linux and 1 OBSD qmail servers... not sure how
that relates though.
Toni Mueller
Hello,
On Thu, Dec 28, 2000 at 10:49:57PM +0100, Henning Brauer wrote:
> Users (or better Admins) without _good_ knowlegde about smtp and mail servers
> AND the underlaying operating system shouldn't run mail servers, IMHO.
that's the theory, and the practise is that most everyone sets up, or has set up,
their stock Suse or Redhat with sendmail-something or postfix and qpopper
(blech), or winblows with MDaemon or Exchange, not knowing what the difference
between a web server, mail server, file server or print server is
(almost :( ), while a small crowd of enlightened few preaches the right
way (TM) to security and system administrations...
While I don't want to say that there are better things to do than to run
MDaemon or so, I feel that lowering the barrier to running a "real"
system with good defaults should be a good thing. If people are
comfortable with running their sendmail/..../qpopper combo, nothing
will change, relays will probably stay open, qpopper (lately much
worse than sendmail as it seems) will continue to allow anyone
to have root, and we are continued to be disrespected for our deviation
from the main stream (why do we miss to change the main stream in
the first place?).
> Running a secure and powerfull mail server is much more complicated than a
> webserver or such stuff...
Ok, maybe (I don't think a good and powerful web server is easy, btw).
> Have a look at qmail-ldap, there are lots of patches for ISP operation
> included.
This is on my todo list for some time now :(
> > But there is no way to add these features in a clean manner. Everyone
> > hacks away as best as he can.
> And therfore learns a lot about mail server operation - maybe it isn't that
> bad...
One one side I agree, but on the other side this is a rather painful and
slow effort.
> only needed because some sites don't care about RFCs, unfortunately.
Umm, at least the big-dns patch is _required_, imho.
> I found Linux to to be a good choice for a mailserver, but this is another
> discussion.
Yes, although I sort of disagree.
> qmails approch slows down this "find a valid address"-hack a _lot_ and makes
> it harder (but not impossible) to automate - IMHO worth the traffic.
It is as long as you only have small probes, but if these people
have their junk mail software and just blow out their jpeg or so
stuff in large quantities, you may wish to deny this junk before
it hits your pipe & servers. Ok, we experienced this only a very few
times, but that was enough for me (who then enjoys all these double
bounces).
May we end the discussion here?
Best Regards,
--Toni++
Henning Brauer
> Hello,
>
> On Thu, Dec 28, 2000 at 10:49:57PM +0100, Henning Brauer wrote:
> > Users (or better Admins) without _good_ knowlegde about smtp and mail
> > servers AND the underlaying operating system shouldn't run mail servers,
> > IMHO.
>
> that's the theory, and the practise is that most everyone sets up, or has
> set up, their stock Suse or Redhat with sendmail-something or postfix and
> qpopper (blech), or winblows with MDaemon or Exchange, not knowing what the
> difference between a web server, mail server, file server or print server
> is
> (almost :( ), while a small crowd of enlightened few preaches the right
> way (TM) to security and system administrations...
Looks like this is the sad reality :-(((
> While I don't want to say that there are better things to do than to run
> MDaemon or so, I feel that lowering the barrier to running a "real"
> system with good defaults should be a good thing. If people are
> comfortable with running their sendmail/..../qpopper combo, nothing
> will change, relays will probably stay open, qpopper (lately much
> worse than sendmail as it seems) will continue to allow anyone
> to have root, and we are continued to be disrespected for our deviation
> from the main stream (why do we miss to change the main stream in
> the first place?).
>
> > Running a secure and powerfull mail server is much more complicated than
> > a webserver or such stuff...
>
> Ok, maybe (I don't think a good and powerful web server is easy, btw).
no, not easy, but _ways_ easier than a secire, powerfull high-volume
mailserver. Setting up a secure, fast webserver is relatively easy, get
appropriate hardware and spend some time for tuning OpenBSD + Apache. Once
reached the target, it's almost possible to forget the machine - it simply
does its job (of course you should set up a second one for redundancy). If
you further have written good management tools...
(one of the greatest things in OpenBSD for that task is the non-existance of
the 256 apache process limit - on linux there are _lots_ of kernel changes
needed. Even then, linux behaviour under DoS is a nightmare while OpenBSD
doesn't realy care about :-)))) )
Our qmail-ldap-cluster took lot's of work more, needed some custom coding
(smtp after pop, accounting stuff, dash-trick for ezmlm, ...) and much
fiddeling around with system parameters - but is now really secure and
scalable to millions of users.
> > Have a look at qmail-ldap, there are lots of patches for ISP operation
> > included.
> This is on my todo list for some time now :(
I'm currently writing on "life with qmail-ldap", available at
http://www.lifewithqmail.org/ldap/
> > > But there is no way to add these features in a clean manner. Everyone
> > > hacks away as best as he can.
> > And therfore learns a lot about mail server operation - maybe it isn't
> > that bad...
> One one side I agree, but on the other side this is a rather painful and
> slow effort.
As always, the medal has two sides.
> > only needed because some sites don't care about RFCs, unfortunately.
> Umm, at least the big-dns patch is _required_, imho.
In theory: no. These oversized dns packets are violating RFCs. There was a
statement by Dan Bernstein regarding this, i forgot the URL unfortunately :-((
In pratice: yes.
> > I found Linux to to be a good choice for a mailserver, but this is
> > another discussion.
> Yes, although I sort of disagree.
It's mainly ext2fs vs. ffs, but let's stop this dicussion.
> > qmails approch slows down this "find a valid address"-hack a _lot_ and
> > makes it harder (but not impossible) to automate - IMHO worth the
> > traffic.
> It is as long as you only have small probes, but if these people
> have their junk mail software and just blow out their jpeg or so
> stuff in large quantities, you may wish to deny this junk before
> it hits your pipe & servers. Ok, we experienced this only a very few
> times, but that was enough for me (who then enjoys all these double
> bounces).
qmail's way of handling this has its pros and cons. I prefer this way.
Never had really trouble with this - thanks to well sized servers, enough
bandwith, traffic control and bandwidth not paid by volume ;-))
>
> May we end the discussion here?
We should at least leave the OpenBSD-List ;-))
>
> Best Regards,
> --Toni++
Eric Berthiaume
Best Regards,
--Toni++
I certainly got enuf informations to give it a shot.
Thanks to everyone that helped!
Eric Berthiaume
mave...@up2.com
Angus Scott-Fleming
> It's some time ago i read it and there were some parts i really got angry
> about, but i can't remember completely.
> I remember they told you not to filter outgoing traffic...
You're dodging the issue. In an earlier message on 28 Dec 2000, at
1:18, you wrote:
> Oh please be carefull - there's lots of nonsens in this book,
> opening serious security holes.
Please back this up with specifics - what serious security holes?
---------------------------------------------------------
Angus Scott-Fleming GeoApplications, Tucson, Arizona
ang...@geoapps.com 1-520-290-5038 / fax 1-208-248-3124
---------------------------------------------------------
Henning Brauer
> On 28 Dec 2000, at 2:17, Henning Brauer wrote:
> > It's some time ago i read it and there were some parts i really got angry
> > about, but i can't remember completely.
> > I remember they told you not to filter outgoing traffic...
> You're dodging the issue. In an earlier message on 28 Dec 2000, at
> 1:18, you wrote:
> > Oh please be carefull - there's lots of nonsens in this book,
> > opening serious security holes.
> Please back this up with specifics - what serious security holes?
Not to filter outgoing traffic is a serious hole IMHO.
I explained further stuff in later mails.
Eric Berthiaume
Henning Brauer already explained what those remarks meant.
Is comment where:
"- The first thing coming to my mind I've written in my previous mail,
they tell
you not to filter outgoing traffic - a nightmare.
- The second thing: they are telling you something like "you don't need
to know
more about your firewall's operating system and networking than bla bla
bla"
- do _never_ run a mission critical system and never never never a
firewall
on an operating system you do not understand, you haven't used before.
And be
sure you _understand_ TCP/IP. It might be ok for a home network to do
so, but
they explicitely talk about companies networks. In this case a security
consultant is the better (and in long terms cheaper) alternative."
If you need more details may I suggest another thread ??
Sorry if the comments part is all messed up (damm netscape mail)
Thanks!
Eric Berthiaume
mave...@up2.com
kms...@ix.netcom.com
> Am Donnerstag, 28. Dezember 2000 02:08 schrieb Eric Berthiaume:
>
> > I don't know that much in networking and in security in general to say
> > that this book is total crap or not but what I do know is that its THE
> > only book referenced as an openbsd specific on www.openbsd.com.
>
> I did not say it's total crap.
You gave a very vague and nonspecific dis of the book. Which *is* total
crap.
> The first thing coming to my mind I've written in my previous mail,
> they tell you not to filter outgoing traffic - a nightmare.
OK, anything else?
> The second thing: they are telling you something like "you don't need
> to know more about your firewall's operating system and networking
> than bla bla bla"
Hardly.
The first section of the book addresses various network protocols and
issues concerning them. The last section of the book addresses
intrusion detection and ongoing vigilance. There *is* fairly specific
detail on building, and testing, firewall rules, including a very useful
troubleshooting section. The system installation guide is pretty good,
and as a long-time GNU/Linux user, I managed to get through a novel
process on the third try (first was a dry run, second was "OK, let's do
it", third was "let's not do *that* this time"). That's better than
most of my GNU/Linux installs.
There were also some issues with the book, some of them my fault, some
of them dated material. I tried to deploy my first obsd box without
reading all the material and missed a couple of key points (internal
modems, COM ports, and IRQ settings). The book is based on 2.6, and
there are some significant differences in command and syntax with 2.7.
I found some of the firewall suggestions to be overly permissive -- for
example I'd lock down ports 6000 - 6064 against external access, my X
sessions are mine, thank you very much. But all told, the rules are a
good start.
I contacted one of the authors (Wes Sonnenreich), found his responses to
be prompt, friendly, and helpful. There's a companion website with
additional and updated information. A revised edition of the book will
focus more on intrusion detection, and add material on topics such as
honeypots.
In all, I found the book a useful resource with intelligent discussion
of security issues. Hardly "Firewalls for Numskulls".
> - do _never_ run a mission critical system and never never never a
> firewall on an operating system you do not understand, you haven't
> used before. And be sure you _understand_ TCP/IP.
Is a firewall book the right place to teach TCP/IP? IMO BLAOF covers
the topic adequately and refers the reader to more complete references
where appropriate. This is good.
> > Do have any books,links,documents that might be more accurate ..
> > security wise ?
>
> puhhh... the best is to learn from practice, what opens up the
> chicken-and-egg problem...
Practice, guided by informed hints and suggestions, is one of my
favorite teachers. It's a complimentary thing.
--
Karsten M. Self <kms...@ix.netcom.com> http://kmself.home.netcom.com/
Evangelist, Zelerate, Inc. http://www.zelerate.org
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org