>> and IMGate can enforce max msg size, offloading that from IMail.
> Won't help--if IMGate enforces max msg size during message submission,
> the clients will have exactly the same problem. Clients that requeue
> 552ed messages will not be "fixed" unless the user receives a
> full-fledged bounce. This is why IMGate would need to have
> unrestricted msg size, then let IMail create the bounce.
More on this, after some more RFC reading. From section 4.5.3.1 of RFC
2821:
> RFC 821 [30] incorrectly listed the error where an SMTP server
> exhausts its implementation limit on the number of RCPT commands
> ("too many recipients") as having reply code 552. The correct reply
> code for this condition is 452. Clients SHOULD treat a 552 code in
> this case as a temporary, rather than permanent, failure...
Technically speaking, then, Outlook is--make sure you're sitting
down--the RFC-compliant one, while The Bat! is applying intelligence
which benefits the end user, but which technically is non-RFC.
You see, Outlook just globally transforms a 552 into a 452, no matter
where in the SMTP conversation it occurs, and requeues. On the other
hand, The Bat! discriminates between a 552 that occurs after a RCPT
command--which is the "too many recipients" documentation error
described above--and a 552 in response to the DATA command. In the
latter case, it takes the 552 "literally" as a permanent rejection and
removes the message from the queue.
This doesn't change the fact the Outlook is acting really stupid, from
a bandwidth and usability point-of-view, but it does explain what M$
programmers were thinking.
-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/
