Exim timeouts - MailScanner related

[Richard Thomas]

Here's some more info on this:

The message is definitely being received by Exim fine. Here is the 
output of a packet capture on the incoming SMTP connection:

<TD WIDTH=1><IMG SRC="http://topica.com/images/footer_cap3.gif" 
WIDTH="1" HEIGHT
="24" BORDER="0"></td>
</tr>
</table>
</center>
<BR><BR><BR><BR>
</body></html>


.
QUIT

Note the two blank lines between the end of the text and the period. 
MailsScanner is picking this up, doing its magic and deposting it in the 
outqueue with a final line that does not end with a CRLF. Exim expects 
this CRLF to be present as it simply adds the period to the end (This 
makes sense if the queue usually works by storing anything up to the 
final period though some sanity checking would be a good thing).

The message affected has been "Disarmed" and web bugs replaced with 
MailScanner warnings if that makes any difference. I would imagine this 
is likely to be a simple fix.

Rich


Richard Thomas wrote:
> Our setup is that we have a mail server which is scanning emails using 
> exim4/mailscanner/spamassassin which then forwards to another server 
> which is just running just exim4. Most of the time, everything is 
> running well but occasionally, I am seeing SMTP data timeouts in the 
> logs of the receiving server. The issue seems to be that when the 
> scanning server sends to the target server, it is not correctly 
> putting the period on a line by itself.
>
> For example, here is the tail end of a file in the exim4 out queue:
>
> /td></td></tr></table></center></body></html>
>
> (No CRLF at the end).
>
> Here is the hexdump of a packet capture on the target server:
>
> 0033220   t   d   >   <   /   t   d   >   <   /   t   r   >   <   /   t
> 0033240   a   b   l   e   >   <   /   c   e   n   t   e   r   >   <   /
> 0033260   b   o   d   y   >   <   /   h   t   m   l   >   .  \r  \n
> 0033277
>
>
> To be honest, at this stage, I'm suspecting exim since it seems to me 
> that it should be able to reasonably handle this situation. But then 
> again, I'm not intimately familiar with the exim queue file format and 
> it could be that it expects it to be properly formatted and 
> MailScanner apparently *has* touched this file so I guess it's 
> possible that it has somehow stripped a required CRLF. I'm at the 
> early stages of troubleshooting at the moment so if anyone has any 
> insight on this, I'd be very grateful to here.
>
> I'll just note that this email was apparently received by the scanning 
> server with no issues.
>
> Rich