Dear Phil and all, Phil Pennock pisze: > On 2007-12-13 at 07:31 +0100, zbigniew szalbot wrote: > > zbigniew szalbot pisze: > > > Thank you Peter - thinking about it, I must admit that at that time > > > the line must have been pretty choked (time to send some 2K emails > > > each about 70KB in size). This could have made it difficult to > > > properly connect and send data to o2.pl. I know exim behaved as > > > expected under given circumstances. To my knowledge o2.pl does not use > > > any greylisting (at least none that I am aware of). Could the reason > > > be bandwidth problems and would/could limits in bandwidth use help me > > > avoid such issues in future? Or is it the fault of the o2.pl server? > > > I now have more information from the o2.pl server admin. They say they > > give 500 error code "when a line in the SMTP protocol extends to more > > than 1024 characters which we treat as not respecting the SMTP protocol > > standards." > > > > I have always thought that exim was very standard-compliant. Could you > > share your thoughts on this? Thank you! > > Zbigniew, you haven't provided your Exim configuration, but I suspect > that what is happening is that these 70KB files are binaries being sent > as raw binaries, so there are no newlines. This is only a suspicion and > might easily be wrong. > > The SMTP server acting as MX for o2.pl advertises 8BITMIME, so they will > accept binary attachments, but the sending MTA (yours) needs to pass > BODY=8BITMIME on the MAIL FROM line. > > Exim does not support 8BITMIME; Exim is 8-bit clean and if given 8-bit > raw data will pass it on, unmolested, but supporting 8BITMIME requires > advertising 8BITMIME yourself and either accepting-then-bouncing when > sending an 8BITMIME message on to a site which does *not* advertise > 8BITMIME (which has a startup problem for migrating) or having the MTA > perform MIME conversion automatically (which is not believed by Exim's > creator to be something that an MTA should do and also breaks > cryptographic signatures). > > So why would Exim be trying to send on such a binary message? There are > two possibilities: > > (1) You have "accept_8bitmime" turned on; this is not a good idea. It > should only be enabled on Exim boxes which receive mail but don't > send it out except to other boxes which are 8bitclean. Exim only > supports the SIZE and AUTH modifiers on outbound email. > > (2) Some mail client is badly broken and sending 8bit data even when > the server doesn't support it, instead of using base64 encoding. > I've even seen mail-clients where the authors decided that they > didn't need to worry about standards and had deliberately decided > that they wouldn't use base64 for sending. :^( > > So, check to see if these rejected mails are binary attachments not > encoded with base64. If they are, either fix your Exim config or fix > the mail-client config. > > It might be that you have non-binaries with very very long lines; that > too is against the mail specifications, but Exim just passes along what > it's given, unmolested. > > If this isn't the problem, then I'm sorry for wasting your time. > Thank you very much for such a detailed explanation! I am bit wiser now :) My exim config does not contain anything about 8bit mime so I am sure this is not the problem. The message was sent using outlook 2003 and I cannot find an option for base64 in this client. Anyway, I decided not to worry about it. It must have been one-off incident. Further messages are sent without any problem.
Thank you again for being so patient with me! All the best! Zbigniew Szalbot -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
