Hello Nick, Friday, May 21, 2004, 10:13:29 PM, you wrote:
NH> Return-Path: <[EMAIL PROTECTED]> NH> Delivered-To: [EMAIL PROTECTED] NH> Received: (qmail 98433 invoked by uid 1017); 21 May 2004 20:24:45 -0000 NH> Received: from venus.teleshop.name NH> by localhost with POP3 (fetchmail-6.2.5) NH> for [EMAIL PROTECTED] (multi-drop); Fri, 21 May 2004 22:24:45 +0200 (CEST) NH> Received: from venus.teleshop.name ([unix socket]) (author=jurgen_0001) NH> by venus.teleshop.name (Cyrus v2.0.17); Fri, 21 May 2004 20:15:43 +0000 NH> X-Sieve: cmu-sieve 2.0 NH> Envelope-to: [EMAIL PROTECTED] NH> Delivery-date: Fri, 21 May 2004 20:15:43 +0000 NH> Received: from mail.inter7.com ([209.218.8.20]) NH> by venus.teleshop.name with smtp (Exim 3.36 #1) NH> id 1BRGQf-000FiL-00 NH> for [EMAIL PROTECTED]; Fri, 21 May 2004 20:15:41 +0000 NH> Received: (qmail 10317 invoked by uid 511); 21 May 2004 20:15:38 -0000 NH> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm NH> Precedence: bulk NH> List-Post: <mailto:[EMAIL PROTECTED]> NH> List-Help: <mailto:[EMAIL PROTECTED]> NH> List-Unsubscribe: <mailto:[EMAIL PROTECTED]> NH> List-Subscribe: <mailto:[EMAIL PROTECTED]> NH> Reply-To: [EMAIL PROTECTED] NH> Delivered-To: mailing list [EMAIL PROTECTED] NH> Received: (qmail 10307 invoked by uid 0); 21 May 2004 20:15:38 -0000 NH> Message-ID: <[EMAIL PROTECTED]> NH> From: Nick Harring <[EMAIL PROTECTED]> NH> To: Nick Harring <[EMAIL PROTECTED]> NH> Date: Fri, 21 May 2004 15:13:29 -0500 NH> MIME-Version: 1.0 NH> X-Mailer: Internet Mail Service (5.5.2655.55) NH> Content-Type: multipart/alternative; NH> boundary="----_=_NextPart_001_01C43F70.5399BB8C" NH> X-Spam-Score: -98.048 Required 6 NH> X-Scanned-By: MIMEDefang 2.37 NH> Subject: Re: Re[2]: [vchkpw] SMTP Auth HOWTO? NH> X-Fetchmail-Warning: recipient address [EMAIL PROTECTED] didn't match any local name NH> On Fri, 2004-05-21 at 14:36, [EMAIL PROTECTED] wrote: >> Hello Nick, >> >> Friday, May 21, 2004, 8:02:19 PM, you wrote: >> >> NH> <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. >> NH> Encrypting traffic between your mail client and your mail server has NH> very little to do with what you're talking about. Keeping email secure NH> is completely different from encrypting the stream of conversation NH> between you and your smtp server. Yes, i understand what You mean. But I am talking about the security issue, not to neglect the security issues when You connect from 'Your home', very often in a C-range/mask 255.255.255.0 with others, You pass a gateway, several routers to reach Your mailserver and You log in, in an unsecured way. With SMTP-auth, You sent in plain or cram Your mailadress and password, which is the same as Your POP(S) account. Every hop can trace Your mailadress and password. Using smtps, You don't have this problem. Encrypting the stream. If You have many customers on the same mailserver, You prefer to encrypt it, because the mail goes encrypted from You to them, and visa versa. There are no other servers involved. I agree on the matter, when You leave Your mailserver to others. In this case, You are correct. NH> Even protecting privacy doesn't really NH> enter into encrypting this stream. NH> Real security comes from applications of cryptography to provide NH> identity and content verification, not just content obfuscation. PGP/GPG NH> signing each email to validate content and identity of origin is a big NH> start. PGP encrypting the contents of sensitive messages directed to NH> specific recipients is an even bigger next step. However the email NH> infrastructure, and its often undirected recipients, makes this a NH> difficult proposition. Right now we have on the serverlevel : virusdetection and spam detection. serverside-signed mails shouldn't be such problem when using the dot qmail ? >> >>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. NH> Sure, however this is significantly more work to configure and maintain. NH> In a large environment this begins to negate the benefits of "virtual" NH> hosting domains. I agree. However, here is something in this thread. When we take a closer look to apache and ssl, we had the same problem some years ago, especialy with the certificates. You could have many virtual hosts, but there was a problem with SSL which provided one certificate for all. Right now, we have virtual hosts (domains) and different SSL cert. So there is a need to rewrite some things to allow the same for the tls issue. >> >> 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. NH> Thats great for you, however with a dozen domains on a 6 server cluster, NH> I really prefer not to think about trying to maintain that. Bringing a NH> single server down for maintenance would be a nightmare all by itself. The same for one mailserver with several virtual domains :-) They are down either when You pull down the mailserver. With a jail You can restart each mailserver, each mailfacility in a separate way :-) >> >> >>(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. NH> Actually I abhor C code. Its hard to read and even harder to write NH> properly. Whats worse is that the more of one you do the more you tend NH> to screw the other. Really well written (i.e. secure and fast) code NH> tends to be unreadable. Really readable code tends to be slow and/or NH> insecure. NH> Perl has overhead, however its not this monstrous thing as people try to NH> claim sometimes. ok : i quote: http://www.nuclearelephant.com/projects/dspam/faq.html#1.7 <snip>While PERL is very useful for language processing and web applications, it is also an extremely slow, interpreted language. The average overhead for a single PERL process is around 2MB of RAM.<snip> >> >> I prefer to gain the speed for other services, instead of loosing it to >> issues as spam. NH> If you have resource issues then I can see this argument, however for NH> those of us with the luxury of providing the resources a large scale NH> email deployment requires will go with ease of administration and NH> maintenance when choosing an application to fill a need rather than NH> "raw" performance. <snip>The 95% accuracy level represents only well-tuned applications of SpamAssassin. Unfortunately, SpamAssassin requires both frequent updating of its rulesets and tuning in order to make it live up to this mediocre level of filtering.<snip> If You study dspam or spamprobe, You have +99% accurancy and a lightspeed spam detecting system. But I agree. Spamass is known for years. And sometimes, it's faster to easy administration and maintenance. But it may not be an excuus to explore other techniques. >> >> 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. NH> I don't use qmail-queue-scanner.pl, I think its a bloated piece of crap. Yes, indeed. So we switched to qscan (for Clamv) NH> I am unwilling to accept its overhead on my server at home that delivers NH> ~100 emails a day, let alone my production environment delivering NH> ~600K/day. NH> This doesn't mean I can't/don't use spamassassin. For those mailboxes NH> electing for spam filtering I use spamc to connect to spamd. Its fast, NH> low overhead, and very easy to maintain. >> >> NH> Cheers, >> NH> Nick Harring >> NH> Webley Systems >> NH> Nick Harring NH> Webley Systems Cheers, -- Best regards, DEBO Jurgen mailto:[EMAIL PROTECTED] -------------------------------------------------------------------------------------------- www.guide.be * www.gids.be * www.guide.fr * www.shop.fr -------------------------------------------------------------------------------------------- / \ sarl GUIDE (sdet) --- the GUIDE, de GIDS, TELESHOP, SHOP __ | __ 128, rue du faubourg de Douai | / | \ | FR-59000 Lille, La France / \ | / \ Tél/Fax +32 59 26.91.51 Mobile +32 479 212.841 /|______\|/______|\ Site http://sarl.guide.fr \| /|\ |/ N° TVA FR-55.440.243.988 |\ / | \ /| RC Lille 74075/2001B01478 |__\ | /__| Siret 440 243 988 00027 | Compte BE: KREDBEBB (BIC) BE56.466-5571951-88 (IBAN) --- Compte FR: CMCIFR2A (BIC) FR76.1562-9027-0200-0455-1870-127 (IBAN) \ / Conditions (terms): http://sarl.guide.fr/conditions.php -------------------------------------------------------------------------------------------- www.teleshop.fr * www.teleshop.be * www.teleshop.biz * www.teleshop.info * www.teleshop.name --------------------------------------------------------------------------------------------
