Hello Nick,

Friday, May 21, 2004, 8:02:19 PM, you wrote:


>>Hello Jeremy,
>>Friday, May 21, 2004, 5:20:40 PM, you wrote:
>>JK> On Friday 21 May 2004 10:21 am, [EMAIL PROTECTED] wrote:
>>>>EH> This is only true for SMTP Authentication of type "plain" and "login".
>>>>EH> With CRAM-MD5 its quite save.
NH> CRAM-MD5 makes it safer, not "quite safe".

>>>>Yes, it's 'quite' safe, but You still reveal Your e-mailadress.
>>>>If there are many hops between Your workstation and the smtpserver,
>>>>You can get some spam in return.
>>JK> I am truly amazed at that statement.
NH> This sounds pretty ridiculous to me also. People who spend inordinate
NH> amounts of time actually worrying about having their traffic sniffed,
NH> probably shouldn't be using anything remotely resembling common internet
NH> protocols.

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.

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

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.

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

I prefer to gain the speed for other services, instead of loosing it to
issues as spam.

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