Re: Re[2]: [vchkpw] SMTP Auth HOWTO?

[Nick Harring]

Title: Re: Re[2]: [vchkpw] SMTP Auth HOWTO?

On Fri, 2004-05-21 at 14:36, [EMAIL PROTECTED] wrote:
> Hello Nick,
>
> Friday, May 21, 2004, 8:02:19 PM, you wrote:
>
>
<snip>
> NH> <snip>
>
> Privacy issues are hot topic, You known.  If You known, some
> 'sensitive' data is often maintained with a single mailbox.  I give
> You some samples.  A domainname You own, which can be stolen by
> impersonating You, by a hacked mailbox.  Or someone, who use Your
> mailbox to contact your customers (if You have a company).  Ok, with
> all worms out, it's common mailboxes are often spoofed, but it's
> realy embarrassing if the mail comes from Your servers !  When Your
> mailserver is server hops away from You,  You consider encrypting the
> route to it.  I wouldn't care someone snifs my browsing attitudes, but
> I wan't to keep my mails to my customers, my mails to maintain cvs or
> domainnaims protected, so it all starts with a secure mailserver.
>
Encrypting traffic between your mail client and your mail server has
very little to do with what you're talking about. Keeping email secure
is completely different from encrypting the stream of conversation
between you and your smtp server. Even protecting privacy doesn't really
enter into encrypting this stream.
Real security comes from applications of cryptography to provide
identity and content verification, not just content obfuscation. PGP/GPG
signing each email to validate content and identity of origin is a big
start. PGP encrypting the contents of sensitive messages directed to
specific recipients is an even bigger next step. However the email
infrastructure, and its often undirected recipients, makes this a
difficult proposition.
> >>I agree on this.  But why to promote smtp-auth in plaintext, cram when You have smtps
> >>to secure the stream up to Your mailserver (one step), but in this
> >>step, You 'can' have many hops between You and Your workstation, so
> >>this stream is the first to protect anyway.  I agree on the fact there
> >>aren't many TLS servers, but if everyone do his own part to install
> >>the TLS option, we have in a little decade a much nicer place to have
> >>secure mail transport.  If people stich with smtp-auth, we never get
> >>there.
> >> 
> >>
> NH> Some of us don't actually have the luxury of smtp-tls because we have
> NH> one physical mail server, or cluster thereof, serving multiple domains.
>
> One physical server can hold many virtual servers in a Unix jail
> environment.
Sure, however this is significantly more work to configure and maintain.
In a large environment this begins to negate the benefits of "virtual"
hosting domains.
>
> NH> These domains are all "hidden" from each other, so unless we start
> NH> running separate smtpd instances, with their own configs, separate IPs
> NH> we cannot present a certificate to each client that'd match what their
> NH> mail client expects.
>
> Well, we do it that way.  By the Jails and IP aliases.
Thats great for you, however with a dozen domains on a 6 server cluster,
I really prefer not to think about trying to maintain that. Bringing a
single server down for maintenance would be a nightmare all by itself.
>
> >>(note: even Your soft, courier-imap seems to have an option for
> >>spamass, would be nice to see Dspam(.org) instead)
> >> 
> >>
> NH> I think this'd be a "show us the code" request. There are quite a few
> NH> ways to use spamassassin where its not a ridiculous memory hog
> NH> (spamc/spamd for one).
>
> I prefer C code, don't You ? Take a look to dspam.  Afterwards, You
> may have another point of view.  With spam-ass You don't have
> problems, if You have a small user base.  When You have a lot of users
> on Your mailserver, it brings any server to it knees, regardless of
> any setup.  It's the overhead of perl.
Actually I abhor C code. Its hard to read and even harder to write
properly. Whats worse is that the more of one you do the more you tend
to screw the other. Really well written (i.e. secure and fast) code
tends to be unreadable. Really readable code tends to be slow and/or
insecure.
Perl has overhead, however its not this monstrous thing as people try to
claim sometimes.
>
> I prefer to gain the speed for other services, instead of loosing it to
> issues as spam.
If you have resource issues then I can see this argument, however for
those of us with the luxury of providing the resources a large scale
email deployment requires will go with ease of administration and
maintenance when choosing an application to fill a need rather than
"raw" performance.
>
> Qmail is a great server, but if You use perl scripts 'to manipulate'
> the mailqueue, You have something to worry about.  Each e-mail
> triggers the scripts, first qmail-scanner, secondly spamm-ass.
I don't use qmail-queue-scanner.pl, I think its a bloated piece of crap.
I am unwilling to accept its overhead on my server at home that delivers
~100 emails a day, let alone my production environment delivering
~600K/day.
This doesn't mean I can't/don't use spamassassin. For those mailboxes
electing for spam filtering I use spamc to connect to spamd. Its fast,
low overhead, and very easy to maintain.
>
> NH> Cheers,
> NH> Nick Harring
> NH> Webley Systems
>
Nick Harring
Webley Systems