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