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

2004-05-21 Thread 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:
> 
> 

> NH> 
> 
> 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.
> 
&g

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

2004-05-21 Thread magazine
Hello Patrick,

Friday, May 21, 2004, 9:34:30 PM, you wrote:

PD> [EMAIL PROTECTED] wrote:
  
PD> Hello Erwin,

PD> Friday, May 21, 2004, 7:37:15 PM, you wrote:

EH>> Hi,

EH>> At 17:21 21.05.04 +0200, you wrote: 

  
  
  
PD> Hello Erwin,

PD> Friday, May 21, 2004, 5:14:30 PM, you wrote:

EH>> Hi,

EH>> At 11:41 21.05.04 +0200, you wrote: 

  
  
  
PD> Hello blist, 

  

  

  
  
  
PD> In the OLD days, people were happy with SMTP-Auth.  I consider it LESS
PD> security as SMTP after POP, because with SMTP-Auth, You sent Your
PD> e-mailadress and Your password of Your mailbox over the internet.
PD> When a man-in-the-middle catch this e-mail (or worse Your PW), he can
PD> use it for spam, or access Your mailbox. 

  

  

  
EH>> This is only true for SMTP Authentication of type "plain" and "login".

EH>> With CRAM-MD5 its quite save.

EH>> Read: http://www.fehcom.de/qmail/smtpauth.html#FRAMEWORK 

  

  

  
 

  
  
  
PD> Yes, it's 'quite' safe, but You still reveal Your e-mailadress.
PD> If there are many hops between Your workstation and the smtpserver,
PD> You can get some spam in return. 

  

  

  
 

  
  
  
PD> More, Your mail is sent in plaintext.  I prefer encrypted streams,
PD> so SUPP's patch which encrypts the stream with SSL, and authenticate
PD> afterwards (in plaintext) is still the best way to go, it's not a big
PD> effort to realize. 

  

  

  
EH>> Pls. tell us how you intend to communicate to the rest of the world by
EH>> means of email with encrypted addresses.

EH>> You are joking, troll.

EH>> regards.
EH>> --eh.



EH>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/EH>
EH>> Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24

PD> To be rude and without respect, this was the speciality of Your
PD> ancestors when they pretended to be the most bright race on Earth.
PD> For Your records annoo 1914-18, 1940-1945.  Clearly, some can't deny
PD> their roots. 



PD> Ahhh...yes! A flame war...always nice :)

I quote from the one who has bringing 'the gas': EH> You are joking, troll

Well, I did't start.  This list is to help people.  It's not about to be picky
or to be arrogant, if someone share another view, he has the right to put his vision
forward and to defend his case.  You can discuss topics without
insulting people and without words like 'troll', maintained in the
directory of Dr. Erwin Hoffmann.  Maybe I write terrible English, but
I am on the internet for a few decades, and some use our programs
quite a lot in their BSD stuff.  I don't need insults of someone, who
thinks to have the right to insult people, because he has a PhD.

-- 
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
 /|__\|/__|\ Sitehttp://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




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

2004-05-21 Thread magazine
Hello Nick,

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


NH> [EMAIL PROTECTED] 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> 

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
>>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> 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
 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
 /|__\|/__|\ Sitehttp://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




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

2004-05-21 Thread Erwin Hoffmann
Hi,

At 17:21 21.05.04 +0200, you wrote:
>Hello Erwin,
>
>Friday, May 21, 2004, 5:14:30 PM, you wrote:
>
>EH> Hi,
>
>EH> At 11:41 21.05.04 +0200, you wrote:
>>>Hello blist,
>>>
>
>>>In the OLD days, people were happy with SMTP-Auth.  I consider it LESS
>>>security as SMTP after POP, because with SMTP-Auth, You sent Your
>>>e-mailadress and Your password of Your mailbox over the internet.
>>>When a man-in-the-middle catch this e-mail (or worse Your PW), he can
>>>use it for spam, or access Your mailbox.
>
>EH> This is only true for SMTP Authentication of type "plain" and "login".
>
>EH> With CRAM-MD5 its quite save.
>
>EH> Read: http://www.fehcom.de/qmail/smtpauth.html#FRAMEWORK
>

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

>More, Your mail is sent in plaintext.  I prefer encrypted streams,
>so SUPP's patch which encrypts the stream with SSL, and authenticate
>afterwards (in plaintext) is still the best way to go, it's not a big
>effort to realize.

Pls. tell us how you intend to communicate to the rest of the world by
means of email with encrypted addresses.

You are joking, troll.

regards.
--eh.



Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24


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

2004-05-21 Thread magazine
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.

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

>> More, Your mail is sent in plaintext.  I prefer encrypted streams,
>> so SUPP's patch which encrypts the stream with SSL, and authenticate
>> afterwards (in plaintext) is still the best way to go, it's not a big
>> effort to realize.

JK> but most servers out there don't have TLS support so your email still goes
JK> across unencrypted.

JK> for instance, I use smtps to talk to my mail server, purely because I have it
JK> available (I'm not using smtp auth or anything) but I realize that when it
JK> leaves my server it's not encrypted.

JK> If you want end to end encryption of emails, most MUAs support pgp/gpg/s-mime
JK> encryption formats.

JK> -Jeremy

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.

A little bit out of topic, but same can be told about qmail-scanner
and Spamm-ass.  Two memory hogs due to perl.  There are alternatives
like qscan and dspam, but to find info to install it, a mess.  So a
lot use the easy road and stick with those perlscripts and downgrade
their qmailserver.

(note: even Your soft, courier-imap seems to have an option for
spamass, would be nice to see Dspam(.org) instead)

-- 
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
 /|__\|/__|\ Sitehttp://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




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

2004-05-21 Thread magazine
Hello Erwin,

Friday, May 21, 2004, 5:14:30 PM, you wrote:

EH> Hi,

EH> At 11:41 21.05.04 +0200, you wrote:
>>Hello blist,
>>

>>In the OLD days, people were happy with SMTP-Auth.  I consider it LESS
>>security as SMTP after POP, because with SMTP-Auth, You sent Your
>>e-mailadress and Your password of Your mailbox over the internet.
>>When a man-in-the-middle catch this e-mail (or worse Your PW), he can
>>use it for spam, or access Your mailbox.

EH> This is only true for SMTP Authentication of type "plain" and "login".

EH> With CRAM-MD5 its quite save.

EH> Read: http://www.fehcom.de/qmail/smtpauth.html#FRAMEWORK

EH> regards.
EH> --eh.

EH> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
EH> Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24

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.

More, Your mail is sent in plaintext.  I prefer encrypted streams,
so SUPP's patch which encrypts the stream with SSL, and authenticate
afterwards (in plaintext) is still the best way to go, it's not a big
effort to realize.

-- 
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
 /|__\|/__|\ Sitehttp://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




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

2004-05-21 Thread magazine
Hello Jeremy,

Friday, May 21, 2004, 3:47:18 PM, you wrote:

JK> On Friday, May 21, 2004 5:41 AM, DEBO Jurgen E. G. wrote:
>> In the OLD days, people were happy with SMTP-Auth. I consider it LESS
>> security as SMTP after POP, because with SMTP-Auth, You sent Your
>> e-mailadress and Your password of Your mailbox over the internet.

JK> Are you insinuating that this is not so with POP3 (or "SMTP after POP") ?

JK> LOL


JK> Jeremy Kister
JK> http://jeremy.kister.com/


No not at all, were do You get this ?  Maybe You read it Your way.
You can authenticate with POP3-SSL, and have a SMTP after POP, so were
is Your point, in this case ?

What I insinuating was to use TLS for SMTP, and not SMTP Auth.

-- 
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
 /|__\|/__|\ Sitehttp://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