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
