Re: Suggestions please for what POP or IMAP servers to use

2007-12-17 Thread Matt LaPlante
On Dec 17, 2007 4:03 AM, Ted Mittelstaedt <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-----
> > From: Matt LaPlante [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, December 15, 2007 2:18 PM
> > To: Ted Mittelstaedt
> > Cc: Andrew Falanga; Rob; FreeBSD Questions
> > Subject: Re: Suggestions please for what POP or IMAP servers to use
> >
> > >
> > > It's a chicken and egg problem.
> > >
> > > There's nothing wrong with writing an extremely strict standard.
> > > The issue is the implementation.
> > >
> > > If your server implementation is so strict that most clients have
> > > difficulty, then users will find something else and your standard
> > > will end up on the dustbin.
> > >
> > > It's better to start out with a strict standard and a forgiving
> > > server implementation, then as it falls into mainstream use, work
> > > with the client developers to correct their stuff.
> >
> > You've effectively described dovecot here.
>
> No, I haven't.
>
> > Its codebase is perhaps
> > designed to be very strict, however the same codebase also includes
> > configurable 'workarounds' (enabled by default in many distros) for
> > clients that are not up to spec.  They're trivial to toggle and well
> > documented.
> >
>
> If you download and compile dovecot then is the default config template
> that is shipped with it enable the workarounds?  No.  The excuse that
> "enabled by default in many distros" is merely an excuse.  Nobody who
> is serious about building a server for a lot of clients is going to
> be using some precompiled version, they are going to compile from
> source so that if a security hole is discovered they can patch it
> immediately.

They're also going to actually *look* at the configuration and tailor
it.  What kind of fool goes to the trouble of building his own
software without also customizing the configuration to his
specifications?

>
> IF the switches DISABLED the "lax" behavior, and the defaults in the config
> templates were to not have the switches triggered, then it would meet the
> definition of a forgiving server implementation.  But it doesen't even
> go that far.
>
> > So, this meets both criteria that it will "just work" with clients
> > now, and the clients themselves could theoretically (good luck with
> > Outlook) fix their code in the future.
>
> Outlook works just fine in IMAP mode with uw-imap, both regular Outlook
> and Outlook Express.
>

I never said it doesn't.  Dovecot works fine with Outlook and Outlook
Express too (both IMAP and POP3).  Imagine that, IMAP servers that
successfully service IMAP clients.

> > As far as I'm concerned, it's
> > a fairly ideal environment,
>
> It is good you spell out that this is your personal ideal.
>
> > and I'm glad the developer has gone to the
> > trouble to 1) stick to standards in the core code and 2) made a point
> > of documenting and providing workarounds for buggy clients.
> >
>
> It is a lot of extra work to encapsulate all the "alleged bugs"
> in separate code so you can provide "switches" for stick-up-their
> -asses-admins to flip.  That is work that should have gone into
> speeding up the code.  It is utterly wasted effort unless your goal
> is to allow admins who have penis envy the ability to jerk people around
> for their choice of e-mail clients.
>
> It isn't the mailserver administrator's business if Joe Idiot User
> who doesen't know any better chooses to use Outlook 97 as an IMAP
> client, to deny Joe Idiot access to the mailserver.  The admin does
> not need to be playing silly games like this, setting up his server
> so that only some clients can work with it, others can't, then telling
> people their software of choice has bugs and fuck you, don't use it.
>
> Programmers jobs are to makes things work for users.  If Mickeysoft's
> programmers cannot write a decent IMAP client, then if the developer
> of an IMAP server can write around the problem, then he should do it
> and embed the fix in the server code without calling it out in a
> config switch.
>
> The situation is absolutely no different with hardware drivers.  Take
> a look at for example the comments in the ne2000  (ed) driver code, or
> the DEC/Intel 21143 network card driver code (or man page)  There are
> a number of very badly borked up hardware implementations of those
> network chipsets.  Yet, do the driver authors of the ed or dc
> driver make the admins flip switches in the 

Re: Suggestions please for what POP or IMAP servers to use

2007-12-15 Thread Matt LaPlante
On Dec 14, 2007 11:45 PM, Ted Mittelstaedt <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Andrew Falanga
> > Sent: Friday, December 14, 2007 7:35 PM
> > To: Ted Mittelstaedt
> > Cc: Rob; FreeBSD Questions
> > Subject: Re: Suggestions please for what POP or IMAP servers to use
> >
> >
> > On Dec 13, 2007 10:06 PM, Ted Mittelstaedt <[EMAIL PROTECTED]> wrote:
> >
> > > > The developer is very adamant about writing dovecot strictly to
> > > > the letter of the IMAP specification.  He's also discovered many
> > > > of the popular clients have bugs, and are unable to work (or at
> > > > least have issues) with an IMAP server that goes purely by the rules.
> > > >
> > > > He refused to "break" his software to work around bugs on the
> > > > client side, but ultimately compromised by writing in
> > > > work-arounds that you can enable in the config file.  You can
> > > > enable them all if you like.
> > > >
> > >
> > > Which is a really dumb attitude since the dovecot developer was
> > > not the author of the IMAP standard and probably was in diapers
> > > when the standard was first written:
> >
> >
> > I agree with your sentiment that, "who can use a server that no client can
> > connect to?"  However, that being said, why write a standard you don't
> > intend to adhere too?  It's a crying shame that folks write standards for
> > things like IMAP and e-mail client providers don't follow them.  I wished
> > more people were like this fellow who writes Dovecot!  If more people were
> > strict about server interfaces, then perhaps more vendors would
> > write their
> > code to the standard instead of those who write the standards
> > enabling poor
> > compliance by "dumbing" down their servers.
> >
>
> It's a chicken and egg problem.
>
> There's nothing wrong with writing an extremely strict standard.
> The issue is the implementation.
>
> If your server implementation is so strict that most clients have
> difficulty, then users will find something else and your standard
> will end up on the dustbin.
>
> It's better to start out with a strict standard and a forgiving
> server implementation, then as it falls into mainstream use, work
> with the client developers to correct their stuff.

You've effectively described dovecot here.  Its codebase is perhaps
designed to be very strict, however the same codebase also includes
configurable 'workarounds' (enabled by default in many distros) for
clients that are not up to spec.  They're trivial to toggle and well
documented.

So, this meets both criteria that it will "just work" with clients
now, and the clients themselves could theoretically (good luck with
Outlook) fix their code in the future.  As far as I'm concerned, it's
a fairly ideal environment, and I'm glad the developer has gone to the
trouble to 1) stick to standards in the core code and 2) made a point
of documenting and providing workarounds for buggy clients.

I personally use dovecot (+postfix) with great success.  Dovecot is
modern, featureful, well documented, and its SASL impementation is
particularly useful with postfix.  I've had no difficulty with clients
not being able to connect.

>
> We don't want to end up like Microsoft - which writes very lax
> and contradictory standards, then makes up strict implementations.
> Then every new release of their stuff breaks things.
>
>
> Ted
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.17.2/1184 - Release Date: 12/14/2007
> 11:29 AM
>
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Apparently, csh programming is considered harmful.

2007-12-13 Thread Matt LaPlante
On Dec 13, 2007 9:59 PM, Chuck Robey <[EMAIL PROTECTED]> wrote:
> Giorgos Keramidas wrote:
> > On 2007-12-13 18:05, Chad Perrin <[EMAIL PROTECTED]> wrote:
> >> I ran across this today:
> >>
> >>   http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
> >>
> >> Title:
> >>   Csh Programming Considered Harmful
>
> That was written sometime last millenium, I mean, it's REALLY old.  The
> question is sort of flamebait (you ought to go ask it on, say, the Linux
> IRC channel, for well-reasoned, adult discussion (NOT!)

One could argue that making irrelevant, potentially insulting
statements about alternative operating systems is:
- not adult
- not well-reasoned
- flamebait

> In general,
> it's right, you really wouldn't want to use tcsh as a scripting
> language.  Read it, you'll come out ahead, but understand, that tcsh is
> a heck of a good general purpose command shell for users.
>
> >>
> >> I wonder what responses I might get here, and how much of this applies
> >> to tcsh as well (I'm still not exactly a tcsh expert).
> >
> > Most of the points made in the FAQ about scripting large `applications'
> > with csh ring a bell for me.  Now, having said that, /bin/sh is nice for
> > small to medium-sized scripts, but there is a certain point where even
> > sh(1) becomes annoying.
> >
> > Do you have any _particular_ parts of the csh-whynot article that you
> > would like to discuss, or this is a free for all flame? :)
> >
> > ___
> > freebsd-questions@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
> ___
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Installer failing dns lookups.

2007-12-02 Thread Matt LaPlante
I will preface this by saying I am not a regular FreeBSD user, and
although I've had a few successful installations in the past, I'm not
very current on the material.

I recently got the itch to try a new FreeBSD install, and not having a
real purpose for the build, I went for some bleeding edge and grabbed
7.0-BETA3-i386-bootonly.iso.  I went through the standard graphical
install, partitioned disks, selected the package set, and all seemed
well.  When I came to the network portion, I selected no IPv6 and yes
DHCP.  DHCP came up correctly from my LAN DHCP server, and I moved on.
 I picked a mirror that didn't yet have beta3 on it (apparently) and
the download failed.  I went to try again, but the next mirror I tried
wouldn't connect.  Pretty soon, the installer was insisting that it
can't find any domains via dns, and that I should check the network
config.  Well sure enough the network settings are right (not
surprising considering they'd *just* worked, and I hadn't changed
them), my dns server is fine, but the installer won't so much as find
ftp.freebsd.org.

I figure hey, that's what you get for trying beta software, let's try
something a little less radical and maybe it will work.  I opt for the
6.3 RC1 bootonly iso next.  Wouldn't you know it, same results.  If
you don't pick a functional mirror on the first try, suddenly the
installer forgets how to look up hosts in dns.  After rebooting the
installer a few times, I manage to confirm that if I get the right
combo on the first time through the installer (ftp passive,
ftp1.us.freebsd.org worked in this case), things work perfectly.  If I
do something silly like trying http without a proxy, or picking a
mirror that doesn't have the distro or doesn't connect, after one or
two cycles dns lookups magically fail and I have to reboot.  Sure
enough, I went back to my 7B3 disc, and using my winning combo of
ftp/passive, ftp1.us, the install works right off the bat.  (Note that
these combinations are just examples of what works for me, right now.
I'm not suggesting that the connection type or the mirror name is
somehow responsible for things being broken; it's merely for
completeness of story.)

So, the essence of this bug report is this:  If I fail to begin the
installation download on the first couple tries, the installer
habitually becomes unable to resolve dns until a reboot is performed.
This affects at least 6.3 and 7.0, but could go back much further.

-
Matt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


FSCK on Reboot

2005-02-16 Thread Matt LaPlante
Right now I've got a server running FreeBSD 4.11.  My question is, is
there a way to automatically run fsck on a system reboot, without
having to go through the process of sitting at the computer, changing
the run level, etc, etc. Clearly it's beneficial in a work environment
to be able to wait till night hours to run such operations, but I
personally have no desire to hang around the office until midnight
just to run a file system check.  I know on any Windows machine this
is easily accomplished by running chkdsk and answering "y" when it
prompts if you want the system checked on the next reboot...you can go
home, wait till midnight, and reboot the system, it will automatically
check itself and come back online.  Can this be accomplished in
FreeBSD?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


RE: Cleaning Out Ports?

2005-02-07 Thread Matt LaPlante
That's correct; this type of functionality is exactly what I was searching
for.


> -Original Message-
> From: Loren M. Lang [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 01, 2005 6:50 AM
> To: Michael C. Shultz
> Cc: freebsd-questions@freebsd.org; Matt LaPlante
> Subject: Re: Cleaning Out Ports?
> 
> 
> There's still one missing part to it that gentoo's portage has.  In
> addition to the standard database of installed packages, emerge keeps
> track
> of every single package that you explicitly installed in a file called
> world.  Upgrades read this file and update all the packages listed,
> including there dependencies first.  Now if a package that was installed
> to satisfy a dependency, but not explicitly installed is now longer
> needed, it will stay on the system until the next time emerge --depclean
> is run.  --depclean tells emerge to remove any packages that are not in
> the world file and are not needed to satify dependencies for packages in
> the world file, either directly or indirectly.  I think this is the
> behavior that the original poster was asking for.  AFAIK, this is not
> yet possible in FreeBSD, but it should be a trivial matter to add
> something like a world file to portupgrade.  Maybe, if I have time this
> week I could work on a patch...
> 
 

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


RE: Cleaning Out Ports?

2005-01-31 Thread Matt LaPlante
This looks like what I'm after, thank you!

> -Original Message-
> From: Michael C. Shultz [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 31, 2005 9:23 PM
> To: freebsd-questions@freebsd.org
> Cc: Matt LaPlante
> Subject: Re: Cleaning Out Ports?
> 
> On Monday 31 January 2005 06:16 pm, Matt LaPlante wrote:
> > Well what I'm more concerned with is how would you locate orphaned
> > dependencies after the fact.  For a parallel example, in gentoo you
> > would "emerge --depclean" which searches the tree for any orphaned
> > packages and removes them.  So say I hadn't used the -r flag when
> > removing packages on BSD, how could I find the leftovers later?
> >
> Look at /usr/ports/sysutils/pkg_cutleaves
> 
> here is a excerpt from its man page:
> 
> "pkg_cutleaves  finds  installed 'leaf' packages, i.e. packages that are
>  not referenced by any other installed package, and lets you decide  for
>  each  one  if  you want to keep or deinstall it (via pkg_deinstall(1)).
> Once the packages marked for  removal  have  been  flushed/deinstalled,
>  you'll  be  asked  if  you want to do another run (to see packages that
>  have become 'leaves' now because you've deinstalled the package(s) that
>  depended  on  them).  In every run you will be shown only packages that
>  you haven't marked for keeping, yet."
> 
> > --
> > Matt LaPlante
> > System Administrator
> > Center for Automation Technologies
> > RPI/CAT, CII 8015
> > 110 8th Street
> > Troy, NY 12180
> > Phone: (518) 276-2275
> > [EMAIL PROTECTED]
> > www.cat.rpi.edu
> >
> > > -Original Message-
> > > From: Pat Maddox [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, January 31, 2005 8:55 PM
> > > To: Matt LaPlante
> > > Cc: freebsd-questions@freebsd.org
> > > Subject: Re: Cleaning Out Ports?
> > >
> > > If you try to remove a package that has child dependencies, then
> > > it'll let you know.  You'll have to use the -f flag to force it to
> > > delete the package, despite there being any dependencies.  If you
> > > want to delete a package along with all its dependencies, you can
> > > use the -r flag.
> > >
> > > Use pkgdb -F to fix any dependencies that might be broken.
> > >
> > > I think that's about right.  I'm a FreeBSD newbie :)
> >
> > ___
> > freebsd-questions@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to
> > "[EMAIL PROTECTED]"

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


RE: Cleaning Out Ports?

2005-01-31 Thread Matt LaPlante
Well what I'm more concerned with is how would you locate orphaned
dependencies after the fact.  For a parallel example, in gentoo you would
"emerge --depclean" which searches the tree for any orphaned packages and
removes them.  So say I hadn't used the -r flag when removing packages on
BSD, how could I find the leftovers later?

--
Matt LaPlante
System Administrator
Center for Automation Technologies
RPI/CAT, CII 8015
110 8th Street
Troy, NY 12180
Phone: (518) 276-2275
[EMAIL PROTECTED]
www.cat.rpi.edu

> -Original Message-
> From: Pat Maddox [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 31, 2005 8:55 PM
> To: Matt LaPlante
> Cc: freebsd-questions@freebsd.org
> Subject: Re: Cleaning Out Ports?
> 
> If you try to remove a package that has child dependencies, then it'll
> let you know.  You'll have to use the -f flag to force it to delete
> the package, despite there being any dependencies.  If you want to
> delete a package along with all its dependencies, you can use the -r
> flag.
> 
> Use pkgdb -F to fix any dependencies that might be broken.
> 
> I think that's about right.  I'm a FreeBSD newbie :)

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Cleaning Out Ports?

2005-01-31 Thread Matt LaPlante

I know the ports system is designed to install dependencies automatically,
but how does one go about removing them?  Say one large package installs
several dependencies, but then later on that package is removed...and now
we're left with several orphaned packages.  Is there a way to either detect,
or even automatically clean out orphaned packages?  I'm particularly
concerned because I'm dealing with a few systems which are rather well aged,
and have gone through several upgrade cycles.  I know the Linux version of
the ports system found in Gentoo (portage) offers extensive functionality
for finding and removing orphaned dependencies, so I'm hoping FreeBSD has
some such feature as well.  Thanks.

-
Matt

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


RE: Courier-IMAP Version?

2004-08-18 Thread Matt LaPlante
> -Original Message-
> From: John Cholewa [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 18, 2004 4:39 PM
> To: Matt LaPlante
> Subject: Re: Courier-IMAP Version?
> 
> Matt LaPlante wrote:
> 
> >I've been working on an old FreeBSD mail server that was configured by a
> >previous sysadmin.  I've attempted to update the Courier-IMAP software,
> but
> >I can't figure out how to verify the installation.  The system was very
> >poorly documented, and I want to be sure the server is actually running
> the
> >newest version.  It's happened to me once or twice before where software
> was
> >installed to an un-standard location, or binaries/configs weren't
> properly
> >updated, so the previous software was actually running instead of the new
> >software.  Unfortunately, I haven't found a way to determine the running
> >version of Courier-IMAP.  Most apps just have a command line -version
> option
> >or will tell you the version if you query them.  How can I make sure the
> >IMAP server that's running is the latest version?  Thanks.
> >
> >
> See if "imapd --version" helps you. It works on mine (I'm apparently
> using version 3.0.2).
> 
> --
>   -JC
>   http://www.jc-news.com/coding/freedom/
>   http://www.jc-news.com/parse.cgi?coding/main
> 
> 
> 
As a matter of fact, it did.  I could swear it didn't work last time I tried
it...

It's not in the man page though, which I KNOW I checked before I wasted your
time.  Thanks. :)

-
Matt


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Courier-IMAP Version?

2004-08-18 Thread Matt LaPlante
I've been working on an old FreeBSD mail server that was configured by a
previous sysadmin.  I've attempted to update the Courier-IMAP software, but
I can't figure out how to verify the installation.  The system was very
poorly documented, and I want to be sure the server is actually running the
newest version.  It's happened to me once or twice before where software was
installed to an un-standard location, or binaries/configs weren't properly
updated, so the previous software was actually running instead of the new
software.  Unfortunately, I haven't found a way to determine the running
version of Courier-IMAP.  Most apps just have a command line -version option
or will tell you the version if you query them.  How can I make sure the
IMAP server that's running is the latest version?  Thanks.

 

-

Matt

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"