Thanks for the insights. You are correct that I am not completely clear on what is happenning, heck I am not very clear on most things!
A couple of questions: When you call outlook a "broken client" I assume you are referring to inherent design flaws in it, rather than any setup of configuration error, right? Yes most all of my users are outlook users, so not much can be done on their end. Thanks for the info on multiple servers and DSN's. I guess this is just one more reason to have another front end server ahead of Imail. I assume that something like IMgate would work for this as well as filling several other purposes? Thanks Dan Spangenberg > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Sanford > Whiteman > Sent: Monday, January 20, 2003 9:46 PM > To: Dan Spangenberg > Subject: Re: [IMail Forum] Max message size and controlling bandwidth > > > > The message never leaves the users outbox, so in 5 or 10 minutes or > > whatever they have their send/receive set to, it tries to send again > > and the whole process starts over again. > > I think you're not completely clear on what is happening: namely, that > this is a client issue. IMail sends a fully informative 552 to the > client, and a smart client (The Bat!, for example) will dequeue the > message and send an alert to the interactive user giving the exact > error for the user to act on. A broken client will treat the 552 as a > transient error (it is not by any means) and will allow the same > message to be attempted, unmodified, during the next send/receive. > > Now, this doesn't stop you from having to deal with broken clients > (such as, I'm guessing, Outlook). But you should know that IMail isn't > at fault for the requeueing. > > Workarounds? If you had an SMTP server with no restrictions that then > forwarded to IMail with restrictions (or vice versa), then users would > get a full DSN. The problem is that when they connect right to your > server with a broken client, there's no DSN. Of course, if you give > them an unrestricted server, you give them a better chance of learning > from their mistakes, but on the flipside you have to continue to eat > the bandwidth. > > > Is it reasonable to have a 6 meg limit on single messages? > > I'd certainly say so. > > > > Do the majority of email servers have message size limits... > > I'd assume so. > > >I wonder though if the servers they are sending to will reject them, > >thus recreating the problem. > > Will they be rejected downstream? Possibly. Same problem? No, because > they'll get a DSN. It's all about getting those with horrible M$ > clients to learn a lesson. Maybe a mail blast in lightly scolding > tones would do the trick just as well: "This is a reminder message > about your maximum message size. Microsoft Outlook has a bug that > causes it to mistakenly requeue messages that are over our limits, > creating the impression that a message has experienced only a > temporary failure. This is not the case; the message will never be > transmitted. Please take care to avoid composing oversize messages to > prevent confusion and dangerous consumption of your bandwidth." > > For more views on a related topic--though substantially different, > since it dealt with RFC-compliant client behaviors, which Outlook's is > not--search the archives for a thread entitled "Hotmail rejection" in > which a few of us squared off on bandwidth abuse. > > -Sandy > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
