The qpopper list archive ending on 19 Feb 2003


Topics covered in this issue include:

  1. 
       
       
  2. Re: Relaying Denied
       Cliff Sarginson <cls at raggedclown dot net>
       Mon, 10 Feb 2003 01:23:48 +0100
  3. Re: Relaying Denied
       Ken Hohhof <ken at mixedsignal dot com>
       Fri, 07 Feb 2003 22:55:35 -0600
  4. Re: Relaying Denied
       Cliff Sarginson <cls at raggedclown dot net>
       Sun, 9 Feb 2003 20:36:41 +0100
  5. Re: Relaying Denied
       Alan Brown <alanb at digistar dot com>
       Mon, 10 Feb 2003 06:02:14 -0500 (EST)
  6. Re: confirmation
       Alan Brown <alanb at digistar dot com>
       Mon, 10 Feb 2003 06:32:53 -0500 (EST)
  7. Problem linking qpopper 404 on Trustix
       Gennaro Esposito <esposito at marscenter dot it>
       Mon, 10 Feb 2003 13:01:56 +0100
  8. Re: Problem linking qpopper 404 on Trustix
       Clifton Royston <cliftonr at lava dot net>
       Mon, 10 Feb 2003 08:27:18 -1000
  9. Re: Relaying Denied
       Simon Byrnand <simon at igrin.co dot nz>
       Tue, 11 Feb 2003 10:08:00 +1300
 10. Re: confirmation
       Clifton Royston <cliftonr at lava dot net>
       Mon, 10 Feb 2003 11:16:09 -1000
 11. Re: confirmation
       Randall Gellens <randy at qualcomm dot com>
       Mon, 10 Feb 2003 14:45:00 -0800
 12. Re: Problem linking qpopper 404 on Trustix
       Randall Gellens <randy at qualcomm dot com>
       Mon, 10 Feb 2003 15:08:13 -0800
 13. Re: A long message on spam and viruses [ was Re: Relaying Denied ]
       Chip Old <fold at bcpl dot net>
       Mon, 10 Feb 2003 08:58:49 -0500 (EST)
 14. Re: confirmation
       Alan Brown <alanb at digistar dot com>
       Tue, 11 Feb 2003 04:46:45 -0500 (EST)
 15. Re: Problem linking qpopper 404 on Trustix
       Randall Gellens <randy at qualcomm dot com>
       Tue, 11 Feb 2003 12:15:45 -0800
 16. Re: confirmation
       Chuck Yerkes <chuck+qpopper at yerkes dot com>
       Mon, 10 Feb 2003 21:38:22 -0500
 17. Re: confirmation
       Randall Gellens <randy at qualcomm dot com>
       Mon, 10 Feb 2003 21:14:44 -0800
 18. Re: Problem linking qpopper 404 on Trustix
       Gennaro Esposito <esposito at marscenter dot it>
       Tue, 11 Feb 2003 10:29:52 +0100
 19. Re: confirmation
       Randall Gellens <randy at qualcomm dot com>
       Mon, 10 Feb 2003 15:03:32 -0800
 20. Re: Relaying Denied
       Cliff Sarginson <cls at raggedclown dot net>
       Tue, 11 Feb 2003 21:10:42 +0100
 21. Re: confirmation
       Alan Brown <alanb at digistar dot com>
       Mon, 10 Feb 2003 19:21:34 -0500 (EST)
 22. Re: Problem linking qpopper 404 on Trustix
       Gennaro Esposito <esposito at marscenter dot it>
       Tue, 11 Feb 2003 10:48:15 +0100
 23. AV (Re: Relaying Denied)
       Chuck Yerkes <chuck+qpopper at yerkes dot com>
       Mon, 10 Feb 2003 02:48:45 -0500
 24. Re: Problem linking qpopper 404 on Trustix
       Alan Brown <alanb at digistar dot com>
       Wed, 12 Feb 2003 12:45:47 -0500 (EST)
 25. Re: Problem linking qpopper 404 on Trustix 
       Ken Hornstein <kenh at cmf.nrl.navy dot mil>
       Wed, 12 Feb 2003 13:09:16 -0500
 26. Re: AV (Re: Relaying Denied)
       Alan Brown <alanb at digistar dot com>
       Wed, 12 Feb 2003 12:42:08 -0500 (EST)
 27. Re: AV (Re: Relaying Denied)
       John Rudd <jrudd at ucsc dot edu>
       Wed, 12 Feb 2003 14:09:58 -0800
 28. Re: Relaying Denied
       Mark <admin at asarian-host dot net>
       Thu, 13 Feb 2003 02:17:16 +0100
 29. newbie need help!!!!
       "yong" <yong80 at oikose dot com>
       Thu, 13 Feb 2003 10:25:52 +0800
 30. Re: newbie need help!!!!
       Alan Brown <alanb at digistar dot com>
       Thu, 13 Feb 2003 04:46:18 -0500 (EST)
 31. META: please remove bluehill.com user
       Alan Brown <alanb at digistar dot com>
       Fri, 14 Feb 2003 11:03:14 -0500 (EST)
 32. Re: qpopper SRPMs
       Kenneth Porter <shiva at sewingwitch dot com>
       Fri, 14 Feb 2003 13:12:24 -0800
 33. Disable IDENT
       Jon Fullmer <jon at jonfullmer dot com>
       Sat, 15 Feb 2003 10:03:25 -0700
 34. Re: Disable IDENT
       The Little Prince <thelittleprince at asteroid-b612 dot org>
       Sat, 15 Feb 2003 09:16:02 -0800 (PST)
 35. Re: Disable IDENT
       Jon Fullmer <jon at jonfullmer dot com>
       Sat, 15 Feb 2003 12:03:37 -0700
 36. Re: Disable IDENT
       Jon Fullmer <jon at jonfullmer dot com>
       Sat, 15 Feb 2003 12:08:26 -0700
 37. Re: Disable IDENT
       "Ken Hohhof" <ken at mixedsignal dot com>
       Sat, 15 Feb 2003 13:47:00 -0600
 38. Re: Disable IDENT
       The Little Prince <thelittleprince at asteroid-b612 dot org>
       Sat, 15 Feb 2003 12:16:02 -0800 (PST)
 39. Re: Disable IDENT
       Daniel Senie <dts at senie dot com>
       Sat, 15 Feb 2003 15:57:00 -0500
 40. Re: Disable IDENT
       Jon Fullmer <jon at jonfullmer dot com>
       Sat, 15 Feb 2003 21:27:45 -0700
 41. compiling Qpopper with kerberos support
       Doh <doh at freemail dot it>
       Mon, 17 Feb 2003 01:44:50 +0100
 42. Temp and cache file locations with home-dir-mail
       Brad Blix <brad at cpinternet dot com>
       Mon, 17 Feb 2003 08:37:12 -0600
 43. Re: Temp and cache file locations with home-dir-mail
       The Little Prince <thelittleprince at asteroid-b612 dot org>
       Mon, 17 Feb 2003 10:11:49 -0800 (PST)
 44. qpopper-mysql-0.8.patch's stability 
       "Caram Bola" <Caram.Bola at comcast dot net>
       Mon, 17 Feb 2003 16:59:16 -0500
 45. Qpopper + SSL + Eudora
       Remy Zandwijk <remy at bio.vu dot nl>
       Tue, 18 Feb 2003 16:24:43 +0100 (MET)
 46. Re: compiling Qpopper with kerberos support 
       Ken Hornstein <kenh at cmf.nrl.navy dot mil>
       Wed, 19 Feb 2003 12:13:27 -0500
 47. Permissions on mail files and /var/mail
       Rick Kunkel <kunkel at w-link dot net>
       Wed, 19 Feb 2003 09:33:09 -0800 (PST)
 48. Re: Permissions on mail files and /var/mail
       Gregory Hicks <ghicks at cadence dot com>
       Wed, 19 Feb 2003 11:07:36 -0800 (PST)
 49. Re: Permissions on mail files and /var/mail
       Rick Kunkel <kunkel at w-link dot net>
       Wed, 19 Feb 2003 11:54:55 -0800 (PST)
 50. Re: Permissions on mail files and /var/mail
       Gregory Hicks <ghicks at cadence dot com>
       Wed, 19 Feb 2003 12:27:15 -0800 (PST)


lows commercial message solicitation but the messages are subject to to a 25 cent per bit delivery fee and all mail users reserve the right to charge 25 cents per bit or the amount agreed to in a settlement as a reader fee All standard mail services are f

or preauthorized emails private in nature  If you do not agree to pay these fees disconnect and do not send your messages)  with SMTP id h1A4gMP10124
	for <qpopper at lists.pensive dot org>; Sun, 9 Feb 2003 22:42:23 -0600
Message-ID: <02ca01c2d0be$cb2023c0$4b02a8c0@destroyer>
From: "James Nelson" <james at digit.bloomnet dot com>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
References: <611149257721783846887 at lists.pensive.org> <576175118020763210538 at lists dot pensive dot org>
Subject: Re: Relaying Denied
Date: Sun, 9 Feb 2003 22:42:12 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
Disposition-Notification-To: "James Nelson" <james at digit.bloomnet dot com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

What if a worm to targets some majorly important domain name and take out
all inbound messaging for the domain via DDOS using this type of issue??
Silly to depend on email for important stuff when you think about it.

----- Original Message -----
From: "Chip Old" <fold at bcpl dot net>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Sunday, February 09, 2003 5:41 PM
Subject: Re: Relaying Denied


> On Sun, 9 Feb 2003 11:43 -0500, Alan Brown wrote:
>
> > On Sun, 9 Feb 2003, Cliff Sarginson wrote:
> >
> > > I "solve" 2 by running antivir on the mail server. This quarantines
> > > mail containing viruses, sends a message to the intended recipient to
> > > say it has done so and a message to the sender,
> > >                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > So you're one of the bastards with malconfigured scanners mailbombing me
> > with virus warnings thanks to most worms using forged addresses. Gee,
> > thanks. What makes you think it's much different to any other form of
> > spam?
>
> Unfortunately an increasing number of people are doing that, both for worm
> e-mail and spam e-mail.  Even worse the practice has actually been
> recommended in various PopTech media.  It's incredibly stupid because the
> sender address on virtually all spam and most current worms is forged.
> At the least, replying generates large numbers of bounced messages.  At
> worst, it floods innocents' mailboxes with messages having nothing to do
> with them.  In either case it creates a lot of unnecessary traffic.  It's
> a really stupid thing to do!
>
> --
> Chip Old (Francis E. Old)             E-Mail:  fold at bcpl dot net
> Manager, BCPL Network Services        Phone:   410-887-6180
> Manager, BCPL.NET Internet Services   FAX:     410-887-2091
> 320 York Road
> Towson, MD 21204  USA
>


Date: Mon, 10 Feb 2003 01:23:48 +0100
From: Cliff Sarginson <cls at raggedclown dot net>
Subject: Re: Relaying Denied

On Sun, Feb 09, 2003 at 03:48:40PM -0800, John Rudd wrote:
> 
> On Sunday, Feb 9, 2003, at 03:28 US/Pacific, Cliff Sarginson wrote:
> >1- Unwanted access to your SMTP Mail server
> >2- Virus Checking
> >3- Spam checking
> >
> >I "solve" 2 by running antivir on the mail server. This quarantines 
> >mail
> >containing viruses, sends a message to the intended recipient to say it
> >has done so and a message to the sender,
> 
> Sending messages back to the sender isn't necessarily a good idea.  
> Mailscanner, which can handle both #2 and #3 via various virus scanning 
> engines, RBL checks, and/or Spam Assassin, has a list of viruses which 
> it silently deletes (no message to the intended recipient nor the 
> claimed sender) because there's just no point.  Many of the Klez 
> family, and a few others, forge the sender address and contain no 
> useful content (as opposed to viruses which attach themselves to some 
> useful data).  So, several of the Klez variants are in Mailscanner's 
> list to "silently delete".
> 
> If you're not doing anything sophisticated on the virus checking side, 
> then I wouldn't bounce any messages back to the sender.  Just filter 
> out the bad attachment and inform the recipient.  Then they can make an 
> informed decision about whether or not to inform the claimed sender.  
> Otherwise, I'd use an engine which knows (or can be told) which viruses 
> it should just delete without further processing.

Ok, that is a good argument, as opposed to one of the others my mail
resulted in. I will give that some careful thought.
I do believe however that the problem is although viruses obviously
originate from malevolent sources they are often passed on by innocent
parties or by people with open-relays etc. In that case, while
discarding it silently it seems kind of important to do whatever little
you can to stop it spreading. I mean I think it is socially
irresponsible to not run virus checkers on incoming and outgoing mail,
particularly on Windows machines .. but some people do not, and they
ought to be aware of the consequences. What I have discovered now
amongst a lot of my friends who use Windows is that they have had it
drilled into them not to open attachments in email messages. Well that
is a protection against certain kind of viruses that are carried that
way, but it is like not going outside your front door in case someone
hits you over the head with a mallet. If a policeman is standing there
you probably will not be. So a virus-checker is like the policeman.

Ah well..this is a many sided argument..but I see the point you are
making. I may turn the auto-reply feature off, but keep the infected 
mail in quarantine to see if anything useful can be gleaned...

-- 
Regards
   Cliff Sarginson 
   The Netherlands

[ This mail has been checked as virus-free ]

Date: Fri, 07 Feb 2003 22:55:35 -0600
From: Ken Hohhof <ken at mixedsignal dot com>
Subject: Re: Relaying Denied

>> Ok, Im game for the SMTP AUTH solution, considering I have RH 7.3 and RH
>8.0
>> boxen, where would I go for a decent tutorial?

If you are using sendmail without a copy of the "bat" book (author
Costales, publisher O'Reilly, 3rd edition, picture of bat on cover) your
first step should be to spend your $59.95 and get one.

Then assuming you have sendmail v8.10 or later, there are very complete
instructions starting with section 10.9 on page 406.

Date: Sun, 9 Feb 2003 20:36:41 +0100
From: Cliff Sarginson <cls at raggedclown dot net>
Subject: Re: Relaying Denied

On Sun, Feb 09, 2003 at 11:43:01AM -0500, Alan Brown wrote:
> On Sun, 9 Feb 2003, Cliff Sarginson wrote:
> 
> > I "solve" 2 by running antivir on the mail server. This quarantines mail
> > containing viruses, sends a message to the intended recipient to say it
> > has done so and a message to the sender,
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> So you're one of the bastards with malconfigured scanners mailbombing me
> with virus warnings thanks to most worms using forged addresses.
> 
No I am not.
Since I don't in the whole history of my virus checker it has detected 2
emails with viruses in them. 2, yes 2. I don;t hang out in circles where
many viruses get sent to me.
Besides which I believe it does a reverse DNS lookup first to check that
the sender is who he says he is. If I though I was causing a mailbomb I
would stop it.

> Gee, thanks. What makes you think it's much different to any other form
> of spam?

It isn't Spam, in many cases it is accidental.
I am not a bastard, and I suggest you cntrol your language and
name-calling on a mailing list when you are not in possession of the
facts.

I happen to now what I am doing.

You might ask yourself why is *someone* forging *your* email address ? 

It sounds to me like any misconfiguration is on your side.

-- 
Regards
   Cliff Sarginson 
   The Netherlands

[ This mail has been checked as virus-free ]


Date: Mon, 10 Feb 2003 06:02:14 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Relaying Denied

On Sat, 8 Feb 2003, Mark wrote:

> A chain is as strong as its weakest link. Meaning, that POP AUTH uses
> plaintext too, of course;

Of course.

> so, unless they use SSL on their POP connections
> as well, users should not bank real money on their passwords being
> unsniffable.

Exactly.

My own servers run pop/imap in ssl mode ONLY.

AB



Date: Mon, 10 Feb 2003 06:32:53 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: confirmation

On Sun, 9 Feb 2003, Randall Gellens wrote:

> DSNs rely on cooperation from every server en route, including the
> final one.

Delivery notices of any sort were pretty much deprecated a long time ago.

If you ever had 20 or 30 UUCP hops sending DSN messages on each message
that was passed through you can understand why.

> I'm not sure DSNs are ever appropriate as "proof" of anything.

They're not - and they won't stand up in court. That's been tried.

All any expert has to say is that by definition, email is _by
definition_ an unreliable mechanism and it's all over.

>  No DSN tells you anything
> about the disposition of the message, by design.

Indeed, and even mail client notices such as "was opened" or "was
deleted, unread" don't mean much due to the triviality of forgery.

As always, if it really has to get through, use certified mail and if
you want to confirm delivery, use a phone call.




Date: Mon, 10 Feb 2003 13:01:56 +0100
From: Gennaro Esposito <esposito at marscenter dot it>
Subject: Problem linking qpopper 404 on Trustix

Greetings
I'm an happy user of qpopper on a DEC OSF/1 platform. Now I'm moving all 
the e-mail services (SMTP and POP...IMAP will follows ;-) ) from that 
platform to an Intel/Trustix (a secured version of RH Linux: 
www.trustix.net)  but I've experienced a problemd in the link phase of the 
poppassd generation. Trustix uses PAM as its user validation architecture 
and I'm using the shadow method.
Hereafter an abstract from the log generated by script command:
-------------------------------------------------------
Script started on Fri Feb  7 19:07:32 2003
root at exd800-01 /sw/qpopper404/qpopper4 dot 0 dot 4# ./configure 
--disable-update-abort --enable-apop
--enable-bulldb=/home/bulldb --enable-group-bulls 
--enable-home-dir-mail=Mailbox --enable-poppassd
--enable-popuid=pop --enable-server-mode --with-pam
<snip....configure and compile ok>
.
.
.
<snip....configure and compile ok>
cd ../password && make all
make[2]: Entering directory `/sw/qpopper404/qpopper4.0.4/password'
gcc -c -I.. -I. -I.. \
          -I../popper -I../common  \
     -g -O2 -DHAVE_CONFIG_H  -DLINUX -DUNIX auth_user.c -o auth_user.o
gcc -c -I.. -I. -I.. \
          -I../popper -I../common  \
     -g -O2 -DHAVE_CONFIG_H  -DLINUX -DUNIX poppassd.c -o poppassd.o
gcc  -o poppassd auth_user.o poppassd.o -lresolv  -ldl -lpam \
            ../common/libcommon.a
poppassd.o: In function `chkPass':
/sw/qpopper404/qpopper4.0.4/password/poppassd.c:1197: undefined reference 
to `auth_user'
collect2: ld returned 1 exit status
make[2]: *** [poppassd] Error 1
make[2]: Leaving directory `/sw/qpopper404/qpopper4.0.4/password'
make[1]: *** [poppassd] Error 2
make[1]: Leaving directory `/sw/qpopper404/qpopper4.0.4/popper'
make: *** [popper_server] Error 2
root at exd800-01 /sw/qpopper404/qpopper4 dot 0 dot 4#
Script done on Fri Feb  7 19:11:56 2003
-------------------------------------------------------

Well, I had a look in the poppassd.c and in the auth_user.c code and in the 
last one I've seen that the auth_user function is inside a nested 
#ifdef  #else condition:
#ifdef SPEC_POP_AUTH
#   ifndef USE_PAM
<....a lot of  auth_user definition for various unix flavors that do not 
use PAM....>
#   endif  /* USE_PAM */
#else /* not SPEC_POP_AUTH */
< a definition of auth_user for systems that do not use shadow or others 
special auth...>
#endif  /* SPEC_POP_AUTH */

In other words: I've both SPEC_POP_AUTH and USE_PAM defined, the dirst 
'cause I use shadow and the second 'cause Trustix use PAM but this seems 
not allowed!
Is it a my fault? Or is it a poppassd coding error?
  Please let me know asap
Thank you in advance

----------
Gennaro Esposito
(System & Security Engineer)
MARS Center                       *****************************
Via E. Gianturco,31               *        YES! I SUPPORT     *
I-80146 - Napoli - ITALY          *                           *
ph.: +39 081-6042 493             *       _/_/  _    _/_/     *
fax...: +39 081-6042 100          *      _/_/===x===_/_/      *
mailto:esposito at marscenter dot it     *     _/_/       _/_/       *
http://www.marscenter.it          *                           *
ftp://ftp.marscenter.it           *International Space Station*
                                   ***************************** 


Date: Mon, 10 Feb 2003 08:27:18 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: Problem linking qpopper 404 on Trustix

On Mon, Feb 10, 2003 at 01:01:56PM +0100, Gennaro Esposito wrote:
> Greetings
> I'm an happy user of qpopper on a DEC OSF/1 platform. Now I'm moving all 
> the e-mail services (SMTP and POP...IMAP will follows ;-) ) from that 
> platform to an Intel/Trustix (a secured version of RH Linux: 
> www.trustix.net)  but I've experienced a problemd in the link phase of the 
> poppassd generation. Trustix uses PAM as its user validation architecture 
> and I'm using the shadow method.

  Unless I am missing something here, if you're using PAM, by
definition you are not using the shadow method.  PAM is a complete
replacement for password validation methods.

> Hereafter an abstract from the log generated by script command:
> -------------------------------------------------------
> Script started on Fri Feb  7 19:07:32 2003
> root at exd800-01 /sw/qpopper404/qpopper4 dot 0 dot 4# ./configure 
> --disable-update-abort --enable-apop
> --enable-bulldb=/home/bulldb --enable-group-bulls 
> --enable-home-dir-mail=Mailbox --enable-poppassd
> --enable-popuid=pop --enable-server-mode --with-pam
> <snip....configure and compile ok>
...
> Well, I had a look in the poppassd.c and in the auth_user.c code and in the 
> last one I've seen that the auth_user function is inside a nested 
> #ifdef  #else condition:
> #ifdef SPEC_POP_AUTH
> #   ifndef USE_PAM
> <....a lot of  auth_user definition for various unix flavors that do not 
> use PAM....>
> #   endif  /* USE_PAM */
> #else /* not SPEC_POP_AUTH */
> < a definition of auth_user for systems that do not use shadow or others 
> special auth...>
> #endif  /* SPEC_POP_AUTH */
> 
> In other words: I've both SPEC_POP_AUTH and USE_PAM defined, the dirst 
> 'cause I use shadow and the second 'cause Trustix use PAM but this seems 
> not allowed!

  Disable SPEC_POP_AUTH (shadow) and see if it builds correctly now?

  -- Clifton

-- 
     Clifton Royston  --  LavaNet Systems Architect --  cliftonr at lava dot net

  "If you ride fast enough, the Specialist can't catch you."
  "What's the Specialist?" Samantha says. 
  "The Specialist wears a hat," says the babysitter. "The hat makes noises."
  She doesn't say anything else.  
                      Kelly Link, _The Specialist's Hat_

Date: Tue, 11 Feb 2003 10:08:00 +1300
From: Simon Byrnand <simon at igrin.co dot nz>
Subject: Re: Relaying Denied

At 20:36 9/02/03 +0100, you wrote:
>On Sun, Feb 09, 2003 at 11:43:01AM -0500, Alan Brown wrote:
> > On Sun, 9 Feb 2003, Cliff Sarginson wrote:
> >
> > > I "solve" 2 by running antivir on the mail server. This quarantines mail
> > > containing viruses, sends a message to the intended recipient to say it
> > > has done so and a message to the sender,
> >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > So you're one of the bastards with malconfigured scanners mailbombing me
> > with virus warnings thanks to most worms using forged addresses.
> >
>No I am not.
>Since I don't in the whole history of my virus checker it has detected 2
>emails with viruses in them. 2, yes 2. I don;t hang out in circles where
>many viruses get sent to me.
>Besides which I believe it does a reverse DNS lookup first to check that
>the sender is who he says he is. If I though I was causing a mailbomb I
>would stop it.

Sorry, but how does a reverse DNS lookup prove the sender is who they say 
they are ? It does no such thing.

> > Gee, thanks. What makes you think it's much different to any other form
> > of spam?
>
>It isn't Spam, in many cases it is accidental.
>I am not a bastard, and I suggest you cntrol your language and
>name-calling on a mailing list when you are not in possession of the
>facts.
>
>I happen to now what I am doing.
>
>You might ask yourself why is *someone* forging *your* email address ?
>
>It sounds to me like any misconfiguration is on your side.

No, it sounds like you don't understand the problem, or how mail is sent.

When most viruses send themselves, they *forge* the envelope sender 
address. This is trivially easy for them to do, as the SMTP protocol does 
not (and can not) verify the sender is who they say they are.

Usually viruses pick an email address at random from the Outlook Express 
address book or Internet Explorer cache, and use that for the envelope 
sender address.

Any virus scanner which replies to the "sender" will reply to this forged 
address who is, in most cases, an innocent bystander, and *NOT* the person 
whose computer sent the virus.

It only takes one computer somewhere on the internet spewing out viruses 
with an innocent bystanders email address as the return address to 
completely swamp the innocent party with virus reports telling them they 
have a virus....

Believe me, it happens, I've seen the results...

Regards,
Simon



Date: Mon, 10 Feb 2003 11:16:09 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: confirmation

On Mon, Feb 10, 2003 at 01:05:22AM +0100, Cliff Sarginson wrote:
...
> > I'm not sure DSNs are ever appropriate as "proof" of anything.  Their 
> > reliability is directly related to the proportion of servers that 
> > support them.  They can be useful.  Certainly a failure DSN is very 
> > useful.
> 
> Oh I don't disagree with failure indications. But you get those anyway.
> But I think mail-systems of any use are built on the "Wells Fargo"
> principle .. "the mail must get through". 

  Then application of a little logic yields the result that Internet
email is not of any use, because the Internet email system as a whole,
including the SMTP protocol, is not built on "the mail must get
through."

  Good admins treat correct delivery of mail (or non-delivery notices)
as an extremely high priority, and so does well-written MTA software. 
However, there is a lot of mail system software in use on the Internet
that does not guarantee this and there are a lot of admins of Internet
systems who really don't care that much.  For example, some MTAs may
acknowledge receipt of mail to the sending client before it is actually
written out to disk, and some admins may deal with some kinds of mail
system problems by deleting everything out of their mail queue in the
course of starting fresh. That makes the Internet as a whole unreliable
as a mail delivery system.

> An indication that it has not
> is good to know (maybe the mailman got shot by a bandit). An indication 
> that it has is a bit overkill...just my view. 
> But it is kind of a lot of baggage isn't it ? 
 
  It is; I agree DSNs are not really very useful.  If you don't get
one, you know that either 1) the mail was not delivered, or 2) it was
delivered to an MTA which doesn't support DSNs.  If you do get one (of
the delivered-to-their-inbox variety) then you know that 1) they will
see it when they next check mail (if they ever check their mail),
unless 2) it is accidentally or intentionally deleted before they
actually see it.  This doesn't seem to add very many bits of
information IMHO.

  Where this originally came in, IIRC, was discussing whether POPping
the mail could trigger an acknowledgement.  That still leaves gaps: it
could be POPped by something like fetchmail and then lost before they
see it; it could be lost because they are using some kind of anti-spam
POP proxy which misclassifies it, etc. etc.


> Maybe one day when email achieves a greater legal status than it has
> now, then non-repudiation of receipt will start to matter.

  I'm sure it will, but I think it will need to be implemented very
differently than it is now.  For those purposes it would need to
include some kind of digital signature or hash on the content of the
email, to avoid various kinds of fraud.

  -- Clifton

-- 
     Clifton Royston  --  LavaNet Systems Architect --  cliftonr at lava dot net

  "If you ride fast enough, the Specialist can't catch you."
  "What's the Specialist?" Samantha says. 
  "The Specialist wears a hat," says the babysitter. "The hat makes noises."
  She doesn't say anything else.  
                      Kelly Link, _The Specialist's Hat_

Date: Mon, 10 Feb 2003 14:45:00 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: confirmation

At 1:05 AM +0100 2/10/03, Cliff Sarginson wrote:

>  Oh I don't disagree with failure indications. But you get those anyway.

The DSN extensions allow you to indicate that you want non-default 
behavior, such as only returning the headers on bounced mail (that 
can cut down on useless traffic) and give you the ability to attach 
unique IDs, which can be incredibly useful when operating a mailing 
list.  But when sites disable DSN support, this isn't possible.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Very funny, Scotty.  Now beam down my clothes.

Date: Mon, 10 Feb 2003 15:08:13 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Problem linking qpopper 404 on Trustix

At 1:01 PM +0100 2/10/03, Gennaro Esposito wrote:

>  #ifdef SPEC_POP_AUTH
>  #   ifndef USE_PAM
>  <....a lot of  auth_user definition for various unix flavors that 
> do not use PAM....>
>  #   endif  /* USE_PAM */
>  #else /* not SPEC_POP_AUTH */
>  < a definition of auth_user for systems that do not use shadow or 
> others special auth...>
>  #endif  /* SPEC_POP_AUTH */
>
>  In other words: I've both SPEC_POP_AUTH and USE_PAM defined, the 
> dirst 'cause I use shadow and the second 'cause Trustix use PAM but 
> this seems not allowed!
>  Is it a my fault? Or is it a poppassd coding error?
>   Please let me know asap
>  Thank you in advance

Not too far from the top of pop_pass.c it has

#ifdef SPEC_POP_AUTH
...
#  ifdef USE_PAM

So, it should work fine to have both defined.
...
However, try 4.0.5b2 just in case that helps.  There were a few bug 
fixes for certain systems.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Never put off till tomorrow what you can avoid alltogether.

Date: Mon, 10 Feb 2003 08:58:49 -0500 (EST)
From: Chip Old <fold at bcpl dot net>
Subject: Re: A long message on spam and viruses [ was Re: Relaying Denied ]

On Mon, 10 Feb 2003 06:18 +0100, Cliff Sarginson wrote:

> On Sun, Feb 09, 2003 at 06:41:23PM -0500, Chip Old wrote:
>
> > Unfortunately an increasing number of people are doing that, both for
> > worm e-mail and spam e-mail.  Even worse the practice has actually
> > been recommended in various PopTech media.  It's incredibly stupid
> > because the sender address on virtually all spam and most current
> > worms is forged.
>
> This discussion is confusing spam and viruses which are two seperate
> issues.

Not at all.  The discussion had shifted to the advisability of
auto-responding to spam and virus-infected messages.  Auto-responding to
either is a bad idea because in most cases the apparant sender address is
bogus.  If you feel differently, by all means feel free to clog your own
mail server (and your customers' mailboxes) with bounced messages and
misdirected auto-replies.  Trouble is you won't affect only your own mail
system.

-- 
Chip Old (Francis E. Old)             E-Mail:  fold at bcpl dot net
Manager, BCPL Network Services        Phone:   410-887-6180
Manager, BCPL.NET Internet Services   FAX:     410-887-2091
320 York Road
Towson, MD 21204  USA

Date: Tue, 11 Feb 2003 04:46:45 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: confirmation

On Mon, 10 Feb 2003, Clifton Royston wrote:

>   Then application of a little logic yields the result that Internet
> email is not of any use, because the Internet email system as a whole,
> including the SMTP protocol, is not built on "the mail must get
> through."

I can think of one MTA which adopts this philosophy - Qmail.

Qmail is one of the most abusive pieces of software I've ever
encountered and its users almost universally adopt attitudes which
border on religious fanaticism. Bandwidth is _NOT_ cheap in large areas
of the world and having some bozo running Qmail drive your networking
costs up 500% unexpectedly is not pleasant.

1: 1 RCPT TO per message instead of as many RCPT TOs as there are local
recipients is a bandwidth attack

2: Opening many parallel SMTP connections to a target server is a state
attack.

In any case, as noted, this is now wandering way off topic.


The only useful DSN I've seen is one which operates at MUA level, but
even the ones which can handle automated confirmation of message opening
can be disabled and won't tell you if the message was opened while the
user was holding down the delete key to wade through the morning's spam.



Date: Tue, 11 Feb 2003 12:15:45 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Problem linking qpopper 404 on Trustix

At 10:48 AM +0100 2/11/03, Gennaro Esposito wrote:

>  Thanks for your answer but the piece of code I sent to the list is 
> from auth_user.c, a module of poppassd daemon.

Sorry about that; I read your message too quickly and didn't notice 
that.  It does appear to be a bug; I think it should be more like 
pop_pass.c
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Citizens for corrupt government, unclean water, higher taxes,
unsafe streets, and poor schools.

Date: Mon, 10 Feb 2003 21:38:22 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: Re: confirmation

.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <705656346801233637214 at lists.pensive dot org>
User-Agent: Mutt/1.4i

Quoting Clifton Royston (cliftonr at lava dot net):
> On Mon, Feb 10, 2003 at 01:05:22AM +0100, Cliff Sarginson wrote:
> ...
> > principle .. "the mail must get through". 
> 
>   Then application of a little logic yields the result that Internet
> email is not of any use, because the Internet email system as a whole,
> including the SMTP protocol, is not built on "the mail must get
> through."
> 
>   Good admins treat correct delivery of mail (or non-delivery notices)
> as an extremely high priority, and so does well-written MTA software. 
> However, there is a lot of mail system software in use on the Internet
> that does not guarantee this and there are a lot of admins of Internet
> systems who really don't care that much.  For example, some MTAs may
> acknowledge receipt of mail to the sending client before it is actually
> written out to disk, 

Which makes it not SMTP, but "SMTP like".  A client had  a term for
a vendor whose software we were replacing:  They are "RFC aware".

data MUST be written to non-volatile storage before being accepted.

> and some admins may deal with some kinds of mail
> system problems by deleting everything out of their mail queue in the
> course of starting fresh. That makes the Internet as a whole unreliable
> as a mail delivery system.

And depending on the problem (massive disk/raid failures), yes that happens.


UDP is, by definition unreliable.  Yet for years we've used NFS and SNMP
over UDP without an issue.  The NFS protocol deals with it at a higher
level.  When you get an ACK from a user that she got the message, then
you can count on her having gotten it.

DSN's are handy in their failures, as pointed out.  Knowing that
a message is still in queue after 4 hours is handy for lots of mail.

Lots of these features came about after X400 came in with its features.
(while really really slow, you could find out where the message was).

We don't want to get rid of the lightweightedness of SMTP and
the rest of store-and-forward that made Usenet and the internet's
subnetworks work. 

Users and admins will not "go for" having their POP server indicate
that they got the mail (hell, fetchmail doesn't mean I've seen it,
it just means that something got it from the spool).

If you want true acknowledgement it must be dealt with at the layer
higher than the transport layer (SMTP/POP in this case).  That
leaves us with the user, right now.

Now, back to qpopper discussions

Date: Mon, 10 Feb 2003 21:14:44 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: confirmation

At 11:16 AM -1000 2/10/03, Clifton Royston wrote:

>   I agree DSNs are not really very useful

There usefulness, in my option, lies mostly in the ability add add 
unique identifiers.  This allows mailing lists to properly handle 
bounces that got passed through forwarding addresses.  It could also 
allow user agents to track message status.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Any idiot can face a crisis, it's this day to day living that wears
you out.                                             --Anton Chekov

Date: Tue, 11 Feb 2003 10:29:52 +0100
From: Gennaro Esposito <esposito at marscenter dot it>
Subject: Re: Problem linking qpopper 404 on Trustix

Hi Clif
Yes, you're missing something ;-)
PAM  (Pluggable Authentication Module) is an authentication architecture 
(this is the keyword) that uses many authentication metods and one of this 
metod is the so-called "shadow". In other words, they are not mutually 
exclusive. You can use shadow, kerberos, and any other authentication 
method "structured" in PAM.
Have a nice day
At 08.27 10/02/2003 -1000, Clifton Royston wrote:
>On Mon, Feb 10, 2003 at 01:01:56PM +0100, Gennaro Esposito wrote:
> > Greetings
> > I'm an happy user of qpopper on a DEC OSF/1 platform. Now I'm moving all
> > the e-mail services (SMTP and POP...IMAP will follows ;-) ) from that
> > platform to an Intel/Trustix (a secured version of RH Linux:
> > www.trustix.net)  but I've experienced a problemd in the link phase of the
> > poppassd generation. Trustix uses PAM as its user validation architecture
> > and I'm using the shadow method.
>
>   Unless I am missing something here, if you're using PAM, by
>definition you are not using the shadow method.  PAM is a complete
>replacement for password validation methods.
>
> > Hereafter an abstract from the log generated by script command:
> > -------------------------------------------------------
> > Script started on Fri Feb  7 19:07:32 2003
> > root at exd800-01 /sw/qpopper404/qpopper4 dot 0 dot 4# ./configure
> > --disable-update-abort --enable-apop
> > --enable-bulldb=/home/bulldb --enable-group-bulls
> > --enable-home-dir-mail=Mailbox --enable-poppassd
> > --enable-popuid=pop --enable-server-mode --with-pam
> > <snip....configure and compile ok>
>...
> > Well, I had a look in the poppassd.c and in the auth_user.c code and in 
> the
> > last one I've seen that the auth_user function is inside a nested
> > #ifdef  #else condition:
> > #ifdef SPEC_POP_AUTH
> > #   ifndef USE_PAM
> > <....a lot of  auth_user definition for various unix flavors that do not
> > use PAM....>
> > #   endif  /* USE_PAM */
> > #else /* not SPEC_POP_AUTH */
> > < a definition of auth_user for systems that do not use shadow or others
> > special auth...>
> > #endif  /* SPEC_POP_AUTH */
> >
> > In other words: I've both SPEC_POP_AUTH and USE_PAM defined, the dirst
> > 'cause I use shadow and the second 'cause Trustix use PAM but this seems
> > not allowed!
>
>   Disable SPEC_POP_AUTH (shadow) and see if it builds correctly now?
>
>   -- Clifton
>
>--
>      Clifton Royston  --  LavaNet Systems Architect --  cliftonr at lava dot net
>
>   "If you ride fast enough, the Specialist can't catch you."
>   "What's the Specialist?" Samantha says.
>   "The Specialist wears a hat," says the babysitter. "The hat makes noises."
>   She doesn't say anything else.
>                       Kelly Link, _The Specialist's Hat_

----------
Gennaro Esposito
(System & Security Engineer)
MARS Center                       *****************************
Via E. Gianturco,31               *        YES! I SUPPORT     *
I-80146 - Napoli - ITALY          *                           *
ph.: +39 081-6042 493             *       _/_/  _    _/_/     *
fax...: +39 081-6042 100          *      _/_/===x===_/_/      *
mailto:esposito at marscenter dot it     *     _/_/       _/_/       *
http://www.marscenter.it          *                           *
ftp://ftp.marscenter.it           *International Space Station*
                                   ***************************** 


Date: Mon, 10 Feb 2003 15:03:32 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: confirmation

At 6:32 AM -0500 2/10/03, Alan Brown wrote:

>  Delivery notices of any sort were pretty much deprecated a long time ago.
>
>  If you ever had 20 or 30 UUCP hops sending DSN messages on each message
>  that was passed through you can understand why.

The DSN extension mechanism was designed to avoid the serious 
problems experienced with the earlier, ad hoc mechanisms, including 
the one you cite.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I settled for being pallid and provincial, out of my own eternal
timidity.                                --Peter Schafer, _Equus_

Date: Tue, 11 Feb 2003 21:10:42 +0100
From: Cliff Sarginson <cls at raggedclown dot net>
Subject: Re: Relaying Denied

I explained at some length my position on this in a previous email.
I have disabled replying to the "sender", but I think the argument has
not necessarily come to the right conclusions. Some people are making
a very complex issue into an over-simplification, because they do not
know how they can block such warnings when they know they never send
virus ridden emails.

Anyway, as far as I am concerned this discussion has come to an end.
When a prominent person on this calls me a bastard, and sends me private
threatening email that he will involve me in an expensive legal court cases 
if he gets a single message from my virus checker (legal nonsense of course, 
he would not have a cat's chance in hell)..and further threatens me that he 
can get me dumped by my ISP because he has lots of contact with Dutch ISP's 
(almost certainly a lie) then things have become pretty pathetic.

This is a serious issue...but this is obviously not really the right
place to discuss it I suppose. 

Yes, I was wrong about the reverse DNS lookup, I must have been thinking
about something else.

The only thing I would add is that the discussion has shown a lot of
people cannot differentiate between spam mail and virus-infections. They
seem to have them all jumbled up in their minds as the same thing.

Anyway..back to qpopper.

-- 
Regards
   Cliff Sarginson 
   The Netherlands

[ This mail has been checked as virus-free ]

Date: Mon, 10 Feb 2003 19:21:34 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: confirmation

On Mon, 10 Feb 2003, Randall Gellens wrote:

> The DSN extension mechanism was designed to avoid the serious
> problems experienced with the earlier, ad hoc mechanisms, including
> the one you cite.

Perhaps, but past experience means that people are very reluctant to
implement such things.




Date: Tue, 11 Feb 2003 10:48:15 +0100
From: Gennaro Esposito <esposito at marscenter dot it>
Subject: Re: Problem linking qpopper 404 on Trustix

Hi  Randall
Thanks for your answer but the piece of code I sent to the list is from 
auth_user.c, a module of poppassd daemon.
I "solved" my trouble simply reconfiguring w/o --enable-poppassd flag.
To the qpopper developers: or poppassd has a programming bug or it was 
designed in such a way and there is a documentation flaw.
Anyway, the problem is not so "hard" as I tought in first istance. Poppassd 
is just an help...
Have a nice day!
At 15.08 10/02/2003 -0800, Randall Gellens wrote:
>At 1:01 PM +0100 2/10/03, Gennaro Esposito wrote:
>
>>  #ifdef SPEC_POP_AUTH
>>  #   ifndef USE_PAM
>>  <....a lot of  auth_user definition for various unix flavors that do 
>> not use PAM....>
>>  #   endif  /* USE_PAM */
>>  #else /* not SPEC_POP_AUTH */
>>  < a definition of auth_user for systems that do not use shadow or 
>> others special auth...>
>>  #endif  /* SPEC_POP_AUTH */
>>
>>  In other words: I've both SPEC_POP_AUTH and USE_PAM defined, the dirst 
>> 'cause I use shadow and the second 'cause Trustix use PAM but this seems 
>> not allowed!
>>  Is it a my fault? Or is it a poppassd coding error?
>>   Please let me know asap
>>  Thank you in advance
>
>Not too far from the top of pop_pass.c it has
>
>#ifdef SPEC_POP_AUTH
>...
>#  ifdef USE_PAM
>
>So, it should work fine to have both defined.
>...
>However, try 4.0.5b2 just in case that helps.  There were a few bug fixes 
>for certain systems.
>
>--
>Randall Gellens
>Opinions are personal;    facts are suspect;    I speak for myself only
>-------------- Randomly-selected tag: ---------------
>Never put off till tomorrow what you can avoid alltogether.

----------
Gennaro Esposito
(System & Security Engineer)
MARS Center                       *****************************
Via E. Gianturco,31               *        YES! I SUPPORT     *
I-80146 - Napoli - ITALY          *                           *
ph.: +39 081-6042 493             *       _/_/  _    _/_/     *
fax...: +39 081-6042 100          *      _/_/===x===_/_/      *
mailto:esposito at marscenter dot it     *     _/_/       _/_/       *
http://www.marscenter.it          *                           *
ftp://ftp.marscenter.it           *International Space Station*
                                   ***************************** 


Date: Mon, 10 Feb 2003 02:48:45 -0500
From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
Subject: AV (Re: Relaying Denied)

Quoting John Rudd (jrudd at ucsc dot edu):
> > From: Daniel Senie <dts at senie dot com>
> > Products which wish to filter spam or viruses 
> > REALLY should be built to "plug in" to mail clients via APIs.
> 
> I disagree.  The proper place to do spam and virus scanning is on the
> server.  Sure, if you want user's to feel some form of warm fuzzy, they
> should have the option to run it on the client (and once there, your
> method might be right).  But the best place to put it is on the server.
> For one, it means that the client hasn't wasted bandwidth downloading
> what may be huge amounts of bad data.

No, it means you pay (without being able to charge through, often)
for a large infrastrcture upgrade because some of your customers
are running virus runtime environments (Outbreak).

Ever scan 50-100,000 message/hour?

Me?  I use mutt mostly. It doesn't get viruses.  More, I've
been hindered from clients trying to send me viruses and
had them blocked by our IT folks.

Why do virus scanning on the end?
"By utilizing the massively distributed, mainly idle systems
 available we are able to be scale our anti-virus capabilities
 far being what we could do without spending 6 figures or more"

Virus "attacks" usually come hard and fast at once.  Server scanning
is a great way to do denial of service on yourself.  Scan
it on landing and those hundreds of 600MHz+ machine out there
scan as the mail comes down.

Given floppies, USB thumb drives, and CDs with Virii (thanks MS
for that one), you must scan on the machine.

It's WAY offtopic for QPopper, but commercial Sendmail (Inc)
has anti-spam and anti-virus milters available for $$$$.

Explore also Sendmail 8.12's "FFR_QUARANTINE" option
(new features can not be added officially without a version
number increase (eg 8.13) and they are tested or in versions
as "FFR_blah").


Me?  I use spamassassin, but mostly get amused at the floods
of viruses trying to run on my BSD/Alpha box.

Now, back to qpopper discussions...

Date: Wed, 12 Feb 2003 12:45:47 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Problem linking qpopper 404 on Trustix

On Tue, 11 Feb 2003, Gennaro Esposito wrote:

> I "solved" my trouble simply reconfiguring w/o --enable-poppassd flag.
> To the qpopper developers: or poppassd has a programming bug or it was
> designed in such a way and there is a documentation flaw.

Poppassd is (or was when I was working on it) a kludge which
simply wraps the existing system passwd command.

If there are any problems with it, it's usually down to the chat
sequence popassd is expecting, vs the sequence it actually got.

AB



Subject: Re: Problem linking qpopper 404 on Trustix
Date: Wed, 12 Feb 2003 13:09:16 -0500
From: Ken Hornstein <kenh at cmf.nrl.navy dot mil>

>PAM  (Pluggable Authentication Module) is an authentication architecture 
>(this is the keyword) that uses many authentication metods and one of this 
>metod is the so-called "shadow". In other words, they are not mutually 
>exclusive. You can use shadow, kerberos, and any other authentication 
>method "structured" in PAM.

A minor pedantic point:

It's not possible to do Kerberos authentication within the PAM framework
(because PAM takes a username/password pair).  It's possible to do
Kerberos PASSWORD authentication, but that's very different from true
Kerberos authentication.

--Ken

Date: Wed, 12 Feb 2003 12:42:08 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: AV (Re: Relaying Denied)

On Mon, 10 Feb 2003, Chuck Yerkes wrote:

> Virus "attacks" usually come hard and fast at once.  Server scanning
> is a great way to do denial of service on yourself.  Scan
> it on landing and those hundreds of 600MHz+ machine out there
> scan as the mail comes down.

If things are that bad, then throttling the server is a good thing, to
be honest.

> Given floppies, USB thumb drives, and CDs with Virii (thanks MS
> for that one), you must scan on the machine.

Yes, but the best approach is (and always has been) "belt, braces,
safety pins"

Just ask the companies who relied on their firewalls to keep out slammer
instead of patching their servers. Several large outfits were fine for a
few days, until slammer got in via a backdoor and then proceeded to
trash the internal network.

> It's WAY offtopic for QPopper, but commercial Sendmail (Inc)
> has anti-spam and anti-virus milters available for $$$$.

Non-commercial sendmail does too. Google on "milter"

The CPU required to filter the average small-medium company isn't
trivial, but it's usually no more than comes as standard with most
desktop systems these days.

> Me?  I use spamassassin, but mostly get amused at the floods
> of viruses trying to run on my BSD/Alpha box.

Ditto, although Tru64/OpenVMS and Linux are the order of the day here.


If people want to be really paranoid, they should look at the F-Prot
stateful firewall. It's not cheap ($50,000 IIRC), but it inspects
everything passing in or out on every port for malicious content.

AB



Date: Wed, 12 Feb 2003 14:09:58 -0800
From: John Rudd <jrudd at ucsc dot edu>
Subject: Re: AV (Re: Relaying Denied)

> From: Chuck Yerkes <chuck+qpopper at yerkes dot com>
>
> Quoting John Rudd (jrudd at ucsc dot edu):
> > > From: Daniel Senie <dts at senie dot com>
> > > Products which wish to filter spam or viruses 
> > > REALLY should be built to "plug in" to mail clients via APIs.
> > 
> > I disagree.  The proper place to do spam and virus scanning is on the
> > server.  Sure, if you want user's to feel some form of warm fuzzy, they
> > should have the option to run it on the client (and once there, your
> > method might be right).  But the best place to put it is on the server.
> > For one, it means that the client hasn't wasted bandwidth downloading
> > what may be huge amounts of bad data.
>
> No, it means you pay (without being able to charge through, often)
> for a large infrastrcture upgrade because some of your customers
> are running virus runtime environments (Outbreak).
>
> Ever scan 50-100,000 message/hour?

We're in the 5-10k messages/hour ball park, 20k-ish users on our actual
systems, plus we relay for the entire campus (even more users).  Our
AV/AS infrastructure, not including the AV software (which is the same
cost whether we use it on the servers or clients, since it's a site
license) cost us less than $8k (a pair of sunblade v150's running
mailscanner+sophos+spamassassin, currently only doing round-robin DNS
based load sharing).  I wouldn't expect our solution to change much,
except in the number of SMTP servers we throw at it, for an increase
of 10x the number of messages. (our current systems could handle twice
the load as it is)  Plus, we'd get a real load balancer.

(though, if I had my druthers, they'd be freebsd or xserve machines)


In fact, that's for our new AV/AS solution.  Our AV solution cost 
SIGNIFICANTLY less and requires much less hardware to work well.
If we were to move spamassassin somewhere else, those 2 sun blades
could easily scale up to the 50k range on just the virus scanning
part (not sure about the network interface bandwidth part).

(our "AV without AS" solution ran on 2 sun ultra-2's for that same
group of traffic, and they were recycled from our previous AFS file
servers)

> Me?  I use mutt mostly. It doesn't get viruses.  More, I've
> been hindered from clients trying to send me viruses and
> had them blocked by our IT folks.
>
> Why do virus scanning on the end?

I don't get infected either.  But it's annoying to wade through
100's or thousands of virus or virus report messages.  And it DOES
impact the time spent by my users (which translates to budget money
wasted in all sorts of ways when the users in question are faculty
or staff).  It also wastes our disk space, slows down our POP server,
etc.  Better to eliminate the viruses before they get to the POP
server, much less the client.

> "By utilizing the massively distributed, mainly idle systems
>  available we are able to be scale our anti-virus capabilities
>  far being what we could do without spending 6 figures or more"

I would rather spend money on the servers, than waste the bandwidth
and processing time on my POP server and client networks.  And, as I
said, the real number is in the low 5 figures, not 6 figures.  Besides,
CPU time is cheap.  Human time is expensive.  Always reduce the human
time. (and the massively distributive solution you mention requires
a LOT of human time to be spent keeping it up to date and in use, where
the central approach requires less than 15 minutes of my time every
90 days)

(and that's low 5 figures for 20k users and 5-10k messages per hour,
at home it cost me _nothing_ to do the same thing on the house mail
server)

If we were to scale up to 50-100k messages/hr, I would still expect
to be in the 5 figure range.

> Virus "attacks" usually come hard and fast at once.

Rarely.  Usually it's a steady flow of about 2% of our overall mail
traffic.  It is exceedingly rare that the virus traffic exceeds 5% of
our traffic, and even more rare that it actually makes a noticible
change in our overall flow statistics.

In fact, looking at the records, neither of those have happened while
we've been gathering the stats.  No, what has historically been the
denial of service type problem is http viruses taking up network
bandwidth when they start trying to probe the network for vulnerable
systems.  

We have had no email viruses that made a significant impact upon our
network bandwidth since putting the sever side solution into place.

> Server scanning
> is a great way to do denial of service on yourself.  Scan
> it on landing and those hundreds of 600MHz+ machine out there
> scan as the mail comes down.
>
> Given floppies, USB thumb drives, and CDs with Virii (thanks MS
> for that one), you must scan on the machine.

File-virus scanning isn't the same as mail-virus scanning, though.
Sure, we allow for both, and have the same software for both, but
if you wait for someone to scan their system (or their floppies,
or the CDs, etc.), they've probably already opened the mail message
in question and done their damage.  If you require that they have a
mail client that has hooks, then you're dictating clients (bad IMO).
And there's other problems if you're requiring locahost proxy's.


Further, doing it on the client depends upon reliable, intelligent,
diligent users (and/or departmental IT folks) keeping their client
machines up to date.  In otherwords, doing it on the client means
it doesn't get done.  Since implementing a server based AV system,
we've had almost zero complaints of email virus infections.  Before
the server based solution, while we also had another virus product
on site license available to all of our users for free, we were
being regularly infected from both off campus and on campus vectors.
Most users weren't using it at all, or weren't using it once it was
installed, or weren't keeping it up to date.

These days, the only problems we see with email viruses are:

a) in the short window between when a new virus emerges and when
sophos releases an update (though, often mailscanner's filename
matching rules handle that), we might get a very few infections.
Though, the complaints don't even make it to the IT discussion
mailing list anymore.

b) users who use remote mail accounts, like hotmail ... and thus
aren't going through our service.  They end up being infected,
and destroying their own data (and maybe launching an http virus),
but they don't infect most other users because those other users
are going through our SMTP servers.

I don't think I've had any user complaints about email viruses in
quite a long time.  It used to be at least a few every month.
Sometimes you'd even get a mob of professors ... and that's not a
pretty sight.  And that was all under the "do it on the client"
method.

> It's WAY offtopic for QPopper, but commercial Sendmail (Inc)
> has anti-spam and anti-virus milters available for $$$$.

Mailscanner is free and rather easy to set up.  It's not a milter
though (it's a dual mailqueue approach).

Amavisd and Mimedefang, which are milters, can work with varous
anti-virus packages and with spamassassin, and are also free.

There's also a package called "blackhole".  I'm not sure what
mechanism it uses, but I'm pretty sure it's not a milter because
it works with multiple MTA's (not just sendmail).


From: Mark <admin at asarian-host dot net>
Date: Thu, 13 Feb 2003 02:17:16 +0100
Subject: Re: Relaying Denied

----- Original Message -----
From: "Cliff Sarginson" <cls at raggedclown dot net>
To: "Subscribers of Qpopper" <qpopper at lists.pensive dot org>
Sent: Tuesday, February 11, 2003 9:10 PM
Subject: Re: Relaying Denied


> The only thing I would add is that the discussion has shown a lot
> of people cannot differentiate between spam mail and virus-infections.
> They seem to have them all jumbled up in their minds as the same
> thing.

No, they have not. :) What they have argued, though -- and successfully so,
as far as I'm concerned -- is that when it comes to contacting the "sender"
of either a spam or a virus-infected email, there is indeed no difference
with regard to the ability, or rather: inability, to determine who the real
sender is.

The inability to determine the real sender extends to SMTP AUTH even, which
does essentially no more than telling you that the sender was authorized to
relay. Since headers, in the SMTP protocol, are part of the DATA stream,
they can be easily faked; or rather, as any other data, they can pretty much
be what you want them to be, save you adhere to their prescribed format.

A mail "wrapper" (such as Sendmail), can, at best, make some marginal checks
on the headers, as to whether sender's hostname resolves, etc. But even that
feature should not be mistaken for authorization; it is, at best, a failsafe
against typos.

So as to make a small contribution to this discussion as well, I have only
two more points to make; for your consideration...

Spam is unsolicited email. Spam is more than just unsolicited email, but is,
by its very definition, always unsolicited. Hence, it must follow that the
remedy to unsolicited email can never, itself, be unsolicited email.

A virus-infected email is, by its very definition, "ill"; that is, even if
you could before (which you cannot, see above), after you made the
determination that an email is infected, you should not trust any part of
that email to contain valid information; the fact that it contains a virus
is proof, in itself, that is has been tampered with. Either a bonafide email
was intercepted, and changed along the way, or it originated as a complete
fake to begin with. Whatever the cause, though, you can no longer trust it;
and especially not for information you cannot even trust when dealing with a
non-infected email: the real sender.

Bottom line: do not send autogenerated replies to the "sender" of either
spam or virus-infected email.

N.B. Do, for instance, what I do. I send out a monthly virus-report to my
users; it tells them who tried to send them a virus-infected email, and who
they, themselves, tried to send one to. Should they recognize certain people
on the list that they feel comfortable enough contacting about it, then I
leave such determination up to them.

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx


From: "yong" <yong80 at oikose dot com>
Subject: newbie need help!!!!
Date: Thu, 13 Feb 2003 10:25:52 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_00A2_01C2D34A.48FEE460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can anyone explain what this error messages mean?

>Failed to create /var/mail/.user.pop with uid 502 gid 12. >Change 
permissions.



------=_NextPart_000_00A2_01C2D34A.48FEE460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; 
charset=iso-8859-1">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Can anyone explain what this error 
messages 
mean?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt;Failed to create 
/var/mail/.user.pop with uid 
502 gid 12. &gt;Change permissions.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00A2_01C2D34A.48FEE460--


Date: Thu, 13 Feb 2003 04:46:18 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: newbie need help!!!!

On Thu, 13 Feb 2003, yong wrote:

> Can anyone explain what this error messages mean?
>
> >Failed to create /var/mail/.user.pop with uid 502 gid 12. >Change permissions.

chmod 1777 /var/mail



Date: Fri, 14 Feb 2003 11:03:14 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: META: please remove bluehill.com user

TIA.

---------- Forwarded message ----------
Date: Fri, 14 Feb 2003 04:32:04 -0800
From: devnull at bluehill dot com
To: alanb at digistar dot com
Subject: Returned mail: Re: AV (Re: Relaying Denied)

+-------------------------------------------------------------+
|             This is a system generated message.             |
|           * Your message has NOT been delivered *           |
+-------------------------------------------------------------+
| This mailbox is protected with an email password system, to |
| have your email delivered please resend the message and     |
| include the string BLUEHILL in the subject.  Thank You!     |
+-------------------------------------------------------------+


Original Message:

>From Qpopper-errors at lists.pensive dot org  Wed Feb 12 13:05:15 2003

[snippage]



Date: Fri, 14 Feb 2003 13:12:24 -0800
From: Kenneth Porter <shiva at sewingwitch dot com>
Subject: Re: qpopper SRPMs

--On Friday, February 14, 2003 11:21 AM -0300 Juan Nin <juan at juanin dot com>
wrote:

> I want to know if you have any qpopper-4 SRPM which does not include DRAC
> support.
> 
> I got a Postfix server with SMTP AUTH support, so I don't want to use
> DRAC. I would like it to be as it comes from Qualcomm with no additional
> features.. do you have any?
> 
> All the ones I've found out there are to be compiled with DRAC support...
> or can I easily compile from that ones disabling it in any way?

Use the source RPM instead of the binary RPM. "Installing" it unpacks it
into the original tarball and a text spec file (plus some extras like
config files that I provide). Edit the spec file to remove the DRAC item
from the configure command, then rebuild the binary RPM with "rpmbuild -ba
qpopper.spec". I recommend also adding your initials to the Release
directive in the spec file so you'll know that this is your custom version
of the RPM.

Date: Sat, 15 Feb 2003 10:03:25 -0700
Subject: Disable IDENT
From: Jon Fullmer <jon at jonfullmer dot com>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3128148205_388072
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I have qpopper 4.0.3 installed on a server running SuSE Linux 7.3 (w/ 2.4.1
9
kernel). I¹ve noticed that each time my users POP to it, it initiates an
IDENT request (TCP 113). I want to disable this. I don¹t need it. After
researching this on the Internet, I¹ve found those that mention that this i
s
possible, but they don¹t mention how. I couldn¹t find anything about this i
n
the Qpopper manual nor in any other documentation.

Is it possible to disable IDENT on qpopper? And if so, how?

Thanks in advance.

 -- Jon Fullmer

--B_3128148205_388072
Content-type: text/html; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Disable IDENT</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana">I have qpopper 4.0.3 installed on a server running SuS
E Linux 7.3 (w/ 2.4.19 kernel). I&#8217;ve noticed that each time my users P
OP to it, it initiates an IDENT request (TCP 113). I want to disable this. I
 don&#8217;t need it. After researching this on the Internet, I&#8217;ve fou
nd those that mention that this is possible, but they don&#8217;t mention ho
w. I couldn&#8217;t find anything about this in the Qpopper manual nor in an
y other documentation.<BR>
<BR>
Is it possible to disable IDENT on qpopper? And if so, how?<BR>
<BR>
Thanks in advance.<BR>
<BR>
&nbsp;-- Jon Fullmer</FONT>
</BODY>
</HTML>


--B_3128148205_388072--


Date: Sat, 15 Feb 2003 09:16:02 -0800 (PST)
From: The Little Prince <thelittleprince at asteroid-b612 dot org>
Subject: Re: Disable IDENT

On Sat, 15 Feb 2003, Jon Fullmer wrote:

> Is it possible to disable IDENT on qpopper? And if so, how?

AFAIK qpopper doesn't have ident support. it's probably your inetd or 
xinetd doing the request.

--Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                            Network Administrator/Engineer
thelittleprince at asteroid-b612.org              http://www.asteroid-b612 dot org

            "This will prove a brave kingdom to me, 
                  where I shall have my music for nothing"
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.


Date: Sat, 15 Feb 2003 12:03:37 -0700
Subject: Re: Disable IDENT
From: Jon Fullmer <jon at jonfullmer dot com>

No, no.  It's the reverse problem.  It's not that I'm feeding requests for
IDENT.  I don¹t even have identd installed, much less a line in the
/etc/inetd.conf file.  What's happening is that when users connect to my
server to POP, the SERVER sends an IDENT request to the client machine
(which usually doesn't run identd anyway).  I just want it to stop doing
that, and I'm not sure how.

 - Jon

on 2/15/03 10:28 AM, Jeff A. Earickson at jaearick at colby dot edu wrote:

> Hi,
>  Edit /etc/inetd.conf.  Look for ident in there.  Comment out
> the line.  Do a "ps" to find the pid number of inetd.  Do a
> "kill -1" on the pid number to have inetd reload the config file.
> Test your work by doing "telnet [name of system] 113".  If identd
> is dead, then you should get a quick "connection refused" message
> back.
> 
> --- Jeff
> 
> On Sat, 15 Feb 2003, Jon Fullmer wrote:
> 
>> Date: Sat, 15 Feb 2003 10:03:25 -0700
>> From: Jon Fullmer <jon at jonfullmer dot com>
>> To: Subscribers of Qpopper <qpopper at lists.pensive dot org>
>> Subject: Disable IDENT
>> 
>> I have qpopper 4.0.3 installed on a server running SuSE Linux 7.3 (w/ 2.
4.19
>> kernel). I¹ve noticed that each time my users POP to it, it initiates an
>> IDENT request (TCP 113). I want to disable this. I don¹t need it. After
>> researching this on the Internet, I¹ve found those that mention that thi
s is
>> possible, but they don¹t mention how. I couldn¹t find anything about thi
s in
>> the Qpopper manual nor in any other documentation.
>> 
>> Is it possible to disable IDENT on qpopper? And if so, how?
>> 
>> Thanks in advance.
>> 
>>  -- Jon Fullmer
>> 
> 


Date: Sat, 15 Feb 2003 12:08:26 -0700
Subject: Re: Disable IDENT
From: Jon Fullmer <jon at jonfullmer dot com>

That certainly could be.  I'm using inetd 1.2.  I didn't see any mention of
IDENT in the inetd documentation or manpages.  There's nothing in the
/etc/inetd.conf file.  I realize this isn't the "inetd" mailing list, but
does anyone know how one would disable this in inetd?

 - Jon

on 2/15/03 10:16 AM, The Little Prince at thelittleprince at asteroid-b612 dot org
wrote:

> On Sat, 15 Feb 2003, Jon Fullmer wrote:
> 
>> Is it possible to disable IDENT on qpopper? And if so, how?
> 
> AFAIK qpopper doesn't have ident support. it's probably your inetd or
> xinetd doing the request.
> 
> --Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco                            Network Administrator/Engineer
> thelittleprince at asteroid-b612.org              http://www.asteroid-b612 dot org
> 
>           "This will prove a brave kingdom to me,
>                 where I shall have my music for nothing"
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> 


From: "Ken Hohhof" <ken at mixedsignal dot com>
Subject: Re: Disable IDENT
Date: Sat, 15 Feb 2003 13:47:00 -0600

> That certainly could be.  I'm using inetd 1.2.  I didn't see any mention
of
> IDENT in the inetd documentation or manpages.  There's nothing in the
> /etc/inetd.conf file.  I realize this isn't the "inetd" mailing list, but
> does anyone know how one would disable this in inetd?

Do you have a line in inetd.conf that starts with "auth" and ends with
"/path/identd" or "/path/in.identd"?  If so, comment it out and restart
inetd.


Date: Sat, 15 Feb 2003 12:16:02 -0800 (PST)
From: The Little Prince <thelittleprince at asteroid-b612 dot org>
Subject: Re: Disable IDENT

this is might be beyond the scope of the problem, but if i were you, i'd 
be using xinetd or tcpserver instead of inetd.

--Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                            Network Administrator/Engineer
thelittleprince at asteroid-b612.org              http://www.asteroid-b612 dot org

            "This will prove a brave kingdom to me, 
                  where I shall have my music for nothing"
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

On Sat, 15 Feb 2003, Jon Fullmer wrote:

> That certainly could be.  I'm using inetd 1.2.  I didn't see any mention of
> IDENT in the inetd documentation or manpages.  There's nothing in the
> /etc/inetd.conf file.  I realize this isn't the "inetd" mailing list, but
> does anyone know how one would disable this in inetd?
> 
>  - Jon
> 
> on 2/15/03 10:16 AM, The Little Prince at thelittleprince at asteroid-b612 dot org
> wrote:
> 
> > On Sat, 15 Feb 2003, Jon Fullmer wrote:
> > 
> >> Is it possible to disable IDENT on qpopper? And if so, how?
> > 
> > AFAIK qpopper doesn't have ident support. it's probably your inetd or
> > xinetd doing the request.
> > 
> > --Tony
> > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > Anthony J. Biacco                            Network Administrator/Engineer
> > thelittleprince at asteroid-b612.org              http://www.asteroid-b612 dot org
> > 
> >           "This will prove a brave kingdom to me,
> >                 where I shall have my music for nothing"
> > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > 
> 
> 

-- 
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                            Network Administrator/Engineer
thelittleprince at asteroid-b612.org              http://www.asteroid-b612 dot org

            "This will prove a brave kingdom to me, 
                  where I shall have my music for nothing"
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.


Date: Sat, 15 Feb 2003 15:57:00 -0500
From: Daniel Senie <dts at senie dot com>
Subject: Re: Disable IDENT

At 02:08 PM 2/15/2003, Jon Fullmer wrote:
>That certainly could be.  I'm using inetd 1.2.  I didn't see any mention of
>IDENT in the inetd documentation or manpages.  There's nothing in the
>/etc/inetd.conf file.  I realize this isn't the "inetd" mailing list, but
>does anyone know how one would disable this in inetd?

Possibly inetd, or you're using tcp wrappers and it's doing it.

I'd start with the man pages and related for both.

xinetd does do ident if you don't instruct it otherwise.

I also have found it useful to apply a filter (iptables/ipchains/etc.) into 
my servers so that any attempt to send a packet to an ident port results in 
(a) a report so I can track down and kill the thing and (b) a reject (ICMP) 
message to the sender. That squelches any program which tries to use ident, 
and allows me to find and fix it. 


Date: Sat, 15 Feb 2003 21:27:45 -0700
Subject: Re: Disable IDENT
From: Jon Fullmer <jon at jonfullmer dot com>

That's IT!  It's not qpopper that's generating these IDENT requests.  It's
not even inetd.  It's the TCPWrappers!

I verified this by having one of my clients FTP to the same server (that's
the only other line open on my inetd.conf).  Once again, IDENT requests were
detected in the client's firewall.  I changed the inetd config line so that
tcp wrappers weren't being used for FTP, had him try again, and no IDENT
requests were made.

The unfortunate part about all this, though, is that I'm still not sure how
to disable this "feature."  In my preliminary research, it appears that I
may have to recompile tcpd.  Either way, this is obviously not a qpopper
problem.  Thanks for all your help!

 -- Jon Fullmer


on 2/15/03 1:57 PM, Daniel Senie at dts at senie dot com wrote:

> At 02:08 PM 2/15/2003, Jon Fullmer wrote:
>> That certainly could be.  I'm using inetd 1.2.  I didn't see any mention of
>> IDENT in the inetd documentation or manpages.  There's nothing in the
>> /etc/inetd.conf file.  I realize this isn't the "inetd" mailing list, but
>> does anyone know how one would disable this in inetd?
> 
> Possibly inetd, or you're using tcp wrappers and it's doing it.
> 
> I'd start with the man pages and related for both.
> 
> xinetd does do ident if you don't instruct it otherwise.
> 
> I also have found it useful to apply a filter (iptables/ipchains/etc.) into
> my servers so that any attempt to send a packet to an ident port results in
> (a) a report so I can track down and kill the thing and (b) a reject (ICMP)
> message to the sender. That squelches any program which tries to use ident,
> and allows me to find and fix it.
> 


Date: Mon, 17 Feb 2003 01:44:50 +0100
From: Doh <doh at freemail dot it>
Subject: compiling Qpopper with kerberos support

hi all,
I'm trying to compile qpopper 4.0.3 with kerberos support
on a mandrake 8.2 linux box (gcc 2.96) with MIT
kerberos 1.2.6 installed and working.
without kerberos support "make" works fine, with
kerberos I get the following error message:


/root/tmp/qpopper4.0.3/common/maillock.c:278: the use of `tempnam' is dangerous, better use `mkstemp'
/usr/local/lib/libkrb5util.a(compat_recv.o): In function `krb_v4_recvauth':
compat_recv.o(.text+0x71c): undefined reference to `krb_net_read'
compat_recv.o(.text+0x756): undefined reference to `krb_net_read'
compat_recv.o(.text+0x7d5): undefined reference to `krb_net_read'
compat_recv.o(.text+0x810): undefined reference to `krb_rd_req'
compat_recv.o(.text+0x89b): undefined reference to `krb_mk_priv'
compat_recv.o(.text+0x8d9): undefined reference to `krb_net_write'
compat_recv.o(.text+0x920): undefined reference to `krb_net_write'
compat_recv.o(.text+0x951): undefined reference to `krb_net_write'
/usr/local/lib/libkrb5.a(hst_realm.o): In function `krb5_try_realm_txt_rr':
hst_realm.o(.text+0x140): undefined reference to `__res_search'
hst_realm.o(.text+0x212): undefined reference to `__dn_expand'
hst_realm.o(.text+0x2b1): undefined reference to `__dn_expand'
/usr/local/lib/libkrb5.a(locate_kdc.o): In function `krb5_locate_srv_dns':
locate_kdc.o(.text+0x92a): undefined reference to `__res_search'
locate_kdc.o(.text+0x9fd): undefined reference to `__dn_expand'
locate_kdc.o(.text+0xa9a): undefined reference to `__dn_expand'
locate_kdc.o(.text+0xd0c): undefined reference to `__dn_expand'
collect2: ld returned 1 exit status
make[1]: *** [popper] Error 1
make[1]: Leaving directory `/root/tmp/qpopper4.0.3/popper'
make: *** [popper_server] Error 2


can anybody help me?
thanks in advance



alessandro garsia



Date: Mon, 17 Feb 2003 08:37:12 -0600
From: Brad Blix <brad at cpinternet dot com>
Subject: Temp and cache file locations with home-dir-mail

Hi,

I am trying to move all of my users mail into their home directories. I
have set  home-dir-mail = MailBox. The problem is that the cache and
temporary files are still being placed in the /var/mail directory. I
have tried setting the check-old-spool-loc to false. Is there any way to
have these files placed in the home directory as well? I noticed that
the cache-name is set to %s.cache. Are there any other variables for the
users home directory so that I could set the cache name to something
like /%h/%s.cache? I searched through the docs and I could not find
anything.

Thanks in advance,

Brad Blix
Senior Network Engineer
CP Internet


Date: Mon, 17 Feb 2003 10:11:49 -0800 (PST)
From: The Little Prince <thelittleprince at asteroid-b612 dot org>
Subject: Re: Temp and cache file locations with home-dir-mail

On Mon, 17 Feb 2003, Brad Blix wrote:

> Hi,
> 
> I am trying to move all of my users mail into their home directories. I
> have set  home-dir-mail = MailBox. The problem is that the cache and
> temporary files are still being placed in the /var/mail directory. I
> have tried setting the check-old-spool-loc to false. Is there any way to
> have these files placed in the home directory as well? I noticed that
> the cache-name is set to %s.cache. Are there any other variables for the
> users home directory so that I could set the cache name to something
> like /%h/%s.cache? I searched through the docs and I could not find
> anything.
> 

umm, i know it's not in the latest (even 4.0.5b2), but it IS in the devel 
tree (which isn't public).
ted, do you have a diff that brad can apply for this functionality in 
the latest stables?

--Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                            Network Administrator/Engineer
thelittleprince at asteroid-b612.org              http://www.asteroid-b612 dot org

            "This will prove a brave kingdom to me, 
                  where I shall have my music for nothing"
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.



From: "Caram Bola" <Caram.Bola at comcast dot net>
Date: Mon, 17 Feb 2003 16:59:16 -0500
Subject: qpopper-mysql-0.8.patch's stability

The Little Prince's (Anthony J. Biacco's?) qpopper-mysql-0.8.patch 
patched, compiled (Maildir capability only, no MySQL) without 
incident against 4.0.4 sources on a Gentoo Linux 2.4.19 box.
The resulting popper daemon seems to be running well (in standalone 
mode) in the same box.

Although I have read the author's disclaimers and understand that 
this is a beta patch, I am still looking for users' comments as to 
its stability on a (very light load) production server.

Thank you.

Caram

Date: Tue, 18 Feb 2003 16:24:43 +0100 (MET)
From: Remy Zandwijk <remy at bio.vu dot nl>
Subject: Qpopper + SSL + Eudora

Hi list.

I installed Qpopper 4.0.4, running as standalone binary. SSL is enabled
and is working correct when users use Outlook. However, when my users
use Eudora (V5.1) and the have choosen to use STLS, it appears there is
no mail in the spool for them. When disabling STLS, there is mail.

The logfile reports 'possible probe for account...' and 'TLS shutdown error'.

What causes this behaviour?


-Remy


Subject: Re: compiling Qpopper with kerberos support
Date: Wed, 19 Feb 2003 12:13:27 -0500
From: Ken Hornstein <kenh at cmf.nrl.navy dot mil>

>/root/tmp/qpopper4.0.3/common/maillock.c:278: the use of `tempnam' is dangerous, be
>tter use `mkstemp'
>/usr/local/lib/libkrb5util.a(compat_recv.o): In function `krb_v4_recvauth':
>compat_recv.o(.text+0x71c): undefined reference to `krb_net_read'
>compat_recv.o(.text+0x756): undefined reference to `krb_net_read'

You need to add -lkrb -ldes425 (and maybe -lresolv) to the link line.

--Ken

Date: Wed, 19 Feb 2003 09:33:09 -0800 (PST)
From: Rick Kunkel <kunkel at w-link dot net>
Subject: Permissions on mail files and /var/mail

Heya all,

I've had a slightly confusing prob that hasn't had a negative effect on
anything, so I've never really taken care of it, but I figured it was time
to ask...

Here are the permissions on my mail dir.....

drwxrwxrwt  4 root  mail  151552 Feb 19 09:23 /var/mail

I'm not exactly sure how this happens, but I end up with the mail files
having either one set of permissions or another.  Both work fie, so
there's no really adverse effects, but my security script complains each
day.  Anyhow, here is an example of each of the types...

-rw-rw----  1 user1             mail         11849 Feb 19 05:51 user1
-rw-------  1 user2             user             0 Feb 18 18:12 user2

I THINK that the local mailer may be responsible for the first type when
we add a new user and they don't have a mail file yet.  When they receive
their first piece of mail, the file is created.

By the way, the local mailer runs as root, sendmail runs as root, and I
believe that qpopper runs as the user.  We're running qpopper in
stand-alone and server mode.

To tell you the truth, I'm not completely sure, and I haven't taken the
time to experiment, which means I probably shouldn't even have written
this email yet, but I thought that if it was something horribly obvious or
well known, someone could throw a suggestion my way...

Thanks!

Rick Kunkel



Date: Wed, 19 Feb 2003 11:07:36 -0800 (PST)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: Re: Permissions on mail files and /var/mail

> Date: Wed, 19 Feb 2003 09:33:09 -0800 (PST)
> From: Rick Kunkel <kunkel at w-link dot net>
> 
> Heya all,
> 
> I've had a slightly confusing prob that hasn't had a negative effect on
> anything, so I've never really taken care of it, but I figured it was time
> to ask...
> 
> Here are the permissions on my mail dir.....
> 
> drwxrwxrwt  4 root  mail  151552 Feb 19 09:23 /var/mail

Your directory (/var/mail) permission are OK since this allows
individual users to modify their own spools.  Some will argue
(discuss?) that these permissions allow a type of DOS (A rogue user
COULD fill the spool and thus deny all other users mail) ...

> I'm not exactly sure how this happens, but I end up with the mail files
> having either one set of permissions or another.  Both work fie, so
> there's no really adverse effects, but my security script complains each
> day.  Anyhow, here is an example of each of the types...
> 
> -rw-rw----  1 user1             mail         11849 Feb 19 05:51 user1
> -rw-------  1 user2             user             0 Feb 18 18:12 user2

The default spool (individual user spool) permissions are 600.  (The
actual DEFAULT permissions are set in sendmail.cf thusly:

# temporary file mode
O TempFileMode=0600
)

If 'something' sets ANY OTHER permissions, those permissions are
preserved even when the spool is 'empty'.  (The file is not deleted and
you have an empty file.)

> I THINK that the local mailer may be responsible for the first type when
> we add a new user and they don't have a mail file yet.  When they receive
> their first piece of mail, the file is created.

Correct.

Hope this helps.

regards,
Gregory Hicks

> By the way, the local mailer runs as root, sendmail runs as root, and I
> believe that qpopper runs as the user.  We're running qpopper in
> stand-alone and server mode.
> 
> To tell you the truth, I'm not completely sure, and I haven't taken the
> time to experiment, which means I probably shouldn't even have written
> this email yet, but I thought that if it was something horribly obvious or
> well known, someone could throw a suggestion my way...
> 
> Thanks!
> 
> Rick Kunkel
> 
> 

-------------------------------------------------------------------
Gregory Hicks                        | Principal Systems Engineer
Cadence Design Systems               | Direct:   408.576.3609
555 River Oaks Pkwy M/S 6B1          | Fax:      408.894.3400
San Jose, CA 95134                   | Internet: ghicks at cadence dot com

"The trouble with doing anything right the first time is that nobody
appreciates how difficult it was."

When a team of dedicated individuals makes a commitment to act as
one...  the sky's the limit.

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Date: Wed, 19 Feb 2003 11:54:55 -0800 (PST)
From: Rick Kunkel <kunkel at w-link dot net>
Subject: Re: Permissions on mail files and /var/mail

I guess I don't understand completely...see below...

> > Here are the permissions on my mail dir.....
> > 
> > drwxrwxrwt  4 root  mail  151552 Feb 19 09:23 /var/mail
> 
> Your directory (/var/mail) permission are OK since this allows
> individual users to modify their own spools.  Some will argue
> (discuss?) that these permissions allow a type of DOS (A rogue user
> COULD fill the spool and thus deny all other users mail) ...

What other permission options would there be?

> > I'm not exactly sure how this happens, but I end up with the mail files
> > having either one set of permissions or another.  Both work fie, so
> > there's no really adverse effects, but my security script complains each
> > day.  Anyhow, here is an example of each of the types...
> >
> > -rw-rw----  1 user1             mail         11849 Feb 19 05:51 user1
> > -rw-------  1 user2             user             0 Feb 18 18:12 user2
>
> The default spool (individual user spool) permissions are 600.  (The
> actual DEFAULT permissions are set in sendmail.cf thusly:
> 
> # temporary file mode
> O TempFileMode=0600
> )

What IS this temp file?  Are they referring to the mail file or the
/var/spool/mqueue/UGLYFILENAME file?

> > I THINK that the local mailer may be responsible for the first type when
> > we add a new user and they don't have a mail file yet.  When they receive
> > their first piece of mail, the file is created.
> 
> Correct.

Any idea why the local mailer (/usr/libexec/mail.local) would be giving
group permissions to the mail file?  They aren't really needed, are they?


Date: Wed, 19 Feb 2003 12:27:15 -0800 (PST)
From: Gregory Hicks <ghicks at cadence dot com>
Subject: Re: Permissions on mail files and /var/mail

> Date: Wed, 19 Feb 2003 11:54:55 -0800 (PST)
> From: Rick Kunkel <kunkel at w-link dot net>
> 
> I guess I don't understand completely...see below...
> 
> > > Here are the permissions on my mail dir.....
> > > 
> > > drwxrwxrwt  4 root  mail  151552 Feb 19 09:23 /var/mail
> > 
> > Your directory (/var/mail) permission are OK since this allows
> > individual users to modify their own spools.  Some will argue
> > (discuss?) that these permissions allow a type of DOS (A rogue user
> > COULD fill the spool and thus deny all other users mail) ...
> 
> What other permission options would there be?

drwxr-xr-x  4 root  mail  151552 Feb 19 09:23 /var/mail

The problem you have here is the user modifying their own file...

> > > I'm not exactly sure how this happens, but I end up with the mail files
> > > having either one set of permissions or another.  Both work fie, so
> > > there's no really adverse effects, but my security script complains each
> > > day.  Anyhow, here is an example of each of the types...
> > >
> > > -rw-rw----  1 user1             mail         11849 Feb 19 05:51 user1
> > > -rw-------  1 user2             user             0 Feb 18 18:12 user2
> >
> > The default spool (individual user spool) permissions are 600.  (The
> > actual DEFAULT permissions are set in sendmail.cf thusly:
> > 
> > # temporary file mode
> > O TempFileMode=0600
> > )
> 
> What IS this temp file?  Are they referring to the mail file or the
> /var/spool/mqueue/UGLYFILENAME file?

This is where the INCOMING mail is stored prior to delivery to the
user's spool in /var/mail.  It has nothing to do with the
/var/spool/mqueue/<ugly-unique-file-name>

> 
> > > I THINK that the local mailer may be responsible for the first type when
> > > we add a new user and they don't have a mail file yet.  When they receive
> > > their first piece of mail, the file is created.
> > 
> > Correct.
> 
> Any idea why the local mailer (/usr/libexec/mail.local) would be giving
> group permissions to the mail file?  

mail.local needs group 'mail' access to the user's spool...

>                                     They aren't really needed, are they?

Yes.  I think so.  I have not delved into the code, nor the logic, but
every mail.local I have seen has worked this way.

Regards,
Gregory Hicks


> 

-------------------------------------------------------------------
Gregory Hicks                        | Principal Systems Engineer
Cadence Design Systems               | Direct:   408.576.3609
555 River Oaks Pkwy M/S 6B1          | Fax:      408.894.3400
San Jose, CA 95134                   | Internet: ghicks at cadence dot com

"The trouble with doing anything right the first time is that nobody
appreciates how difficult it was."

When a team of dedicated individuals makes a commitment to act as
one...  the sky's the limit.

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Last updated on 19 Feb 2003 by Pensive Mailing List Admin