Hello Nick,

Friday, May 21, 2004, 10:13:29 PM, you wrote:

NH> Return-Path: <[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 ([])
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> Delivered-To: mailing list [EMAIL PROTECTED]
NH> Received: (qmail 10307 invoked by uid 0); 21 May 2004 20:15:38 -0000
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 

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 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

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


Best regards,
 DEBO Jurgen

                 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 * 

Reply via email to