sslug-teknik team mailing list archive

[Mogens Valentin <monz@xxxxxxxxx>]

Anders Nielsen wrote:
> Jeg tillader mig lige at stille et tillægsspørgsmål til Klaus og andre
> 
> Hvilke Windows klienter benytter du og hvordan virker de? Jeg har lavet
> nogle små tests med courier-imap over SSL og Outlook 2000 og det har
> faktisk givet nogle problemer. Outlook må nogle gange genstartes flere
> gange om dagen. Muligvis fordi Outlook er skod, men stadig vigtigt hvis
> folk nu _vil_ køre med det.

Det er et evindeligt problem der ofte diskutteres på courier-users
listen.
Summarum:

. Brug den rigtige O/OE version til et given M$ OS. Altså ikke noget med
O/OE for W2K sammen med XP.
. Opdater såvel OS som applikationer.
. Brug fortrinsvis Outlook, ikke OE. OE er en fri downloadable version,
Outlook er en betalingsversion. Ved non-opensource får man nogle gange
hvad man betaler for. Desuden installeres ved Outlook nogle
systemfiler/DLL'er, der gør at 'det virker bedre'.
. Brug sidste version af Courier-imap, dog ikke development versioner.
Der _er_ selvfølgelig blevet løst problemer med produktet gennem tiden.
. Sæt O/OE til kun at checke relevante foldere, ikke samtlige
underfoldere.
I imap læses foldere alligevel når man klikker på dem.
. Sæt O/OE (såmænd ozze andre MUA'er) til kun at checke headers; der er
ingen grund til at spilde netværks/server ressourcer på at hente hele
mails fra 26 foldere med masser af mails i hver. Den fulde mailbody
hentes jo hurtigt når man vil læse en given mail.

Ændrer flg. i imapd conffilen:
  #MAXPERIP=4
  MAXPERIP=15     (eller måske højere, 20-30)
  #IMAP_USELOCKS=0
  IMAP_USELOCKS=1

Kort forklaring:
MAXPERIP: M$ synes ikke man behøver følge gældende RCF standarder, og
holder derfor deres imap connections åbne indtil al evighed, eller til
O/OE/Wxxx lukkes (eller til Wxxx går død, hvilket s'fø'li' sætter en
praktisk begrænsning for hvor længe connections kan være åbne :o:).
Samtidig åbner M$ MUA'er flere samtidige connections ved fx.
drag'n'drop.
IMAP_USELOCKS: Skulle aldrig være nødvendig, men hjælper ofte på O/OE.
Giver noget dårligere performance, men når nu O/OE er noget skod...

Og nope, det er ikke Courier-imap der er problemer med, det er O/OE.
Et særdeles irriterende problem med O/OE er at M$ gennem tiden har
ændret implementering af hvordan deres MUA'er håndterer imap
protokollen.

<DISCLAIMER>
Imap er en standard der giver visse spillerum for hvordan man fx. vil
checke for nye mails. M$ gør dog nogle tåbelige Ting&Sager, som på
courier-users listen gentagne gange er dokumenteret gennem dumps af
kommunikationen mellem O/OE og server.
</DISCLAIMER>

Læs min samling af morsomme diskussioner fra courier-users listen for
bedre forståelse af hvorfor Sam er træt af spørgsmål om O/OE.

-- 
Kind regards / venlig hilsen,
Mogens Valentin, Mr Dev

IT Networking, Security, Server Setup
http://www.mrdev.com  mrdev@xxxxxxxxx
Phone +45 32 525 878  Cell 51 227 668



>From the Courier-users list, when discussing MS-Outlook infinitely
looping
non-RFC garbage commands to an imapserver:

> Few minutes ago I've got this error message from OE:
> "Your IMAP server wishes to alert you to the following: Fatal error: TOO
> MANY CONSECUTIVE PROTOCOL VIOLATIONS:"
>
> That's the funniest error message I've got for some time...

What's even funnier is that it was explicitly designed for MSOE. 
Sometimes
it decides to keep sending the same garbage command over and over again.
Each time the server rejects the command as invalid, it just resends it
again, in an infinite loop.  So, when the server receives too many
consecutive protocol violations, this alert gets sent to the client, and
the connnection gets forcibly terminated.

> Erm... What's now?

Try to find the guy who wrote MSOE, and ask him to fix it.  Or, install
a
random service pack, or a hot fix.  Sometimes they end up fixing these
kinds of things.

> You said by yourself that OE has serious protocol violations.

Only some versions of OE are crippled.  OE's really not OE.  Lots of
stuff
OE does is actually part of MSIE; installing MS Office also installs
some
libraries that are shared with OE.  Depending on the particular
combination
of the official OE version, MSIE version, Windows version,
current+previous
service packs, Office version, and gawd knows what else, you'll see
widely
different behavior from the OE client.

> Maybe it's possible to ignore these garbage commands and not to reject?

Sure, and when the next MSOE rev starts spitting out different garbage,
let's ignore that also.  Let's go even one step further: why not solve
this
problem permanently, by writing a telepathic module that tries to figure
out what MSOE wants, and respond accordingly (instead of the random
collection of bits it sends to the server, they don't mean anything at
all).
  -- Sam Varshavchik