Re: Strange appendlet() error

[Matti Aarnio <mea@nic.funet.fi>]

On Fri, Oct 12, 2001 at 02:04:58PM +0200, Grzegorz Staniak wrote:
> Hi all,
> 
> I'm using zmailer-2.99.52 on an upgraded RedHat 5.2 system, and recently
> I've been experiencing problems with one particular remote SMTP server:

     This is definitely strange.

> 02450V0005687549w       EHLO aaa.bbb.ccc
> 02450V0005787549r       500 Unknown command
> 02450V0005887549w       HELO aaa.bbb.ccc
> 02450V0005987549r       250 Hello aaa.bbb.ccc, pleased to meet you
> 02450V0006087549#       smtpopen: status = 0
> 02450V0006187549w       MAIL From:<user@aaa.bbb.ccc>
> 02450V0006287549r       250 <user@aaa.bbb... Sender ok
> 02450V0006387549w       RCPT To:<anotheruser@xxx.yyy.zzz>
> 02450V0006487549r       250 <anotheruser@xxx.... Recipient ok
> 02450V0006587549w       DATA
> 02450V0006687549r       354 Enter mail, end with "." on a line by itself
> 02450V0006787556#       (closed SMTP channel - appendlet() failure, status=-999)
> 02450V0006887556#       (closed SMTP channel - after delivery failure)
> 02450V0006987556#       jobspec: B/321803-27901 yyy.zzz
> 
> I have no idea what's going on, Google returned a letter published
> on this list sometime in 1998 describing a similar problem, but no
> solution.


     I think I have seen these sometime in the past too.


     I compared appendlet() of 2.99.52 and current, and there is
     very small difference deep inside.

     Selected picks in the ChangeLog tell me:


2000-01-25  Matti Aarnio  <mea@mea.tmt.tele.fi>

	* transports/smtp/smtp.c, transports/smtp/appendlet.c:
	    Small error test rearrangements so that if  sferror()
	    is set at the output stream, no writing will happen.

2000-02-01  Matti Aarnio  <mea@mea.tmt.tele.fi>

	* transports/smtp/appendlet.c, transports/smtp/smtp.h,
	  transports/smtp/smtptls.c,   transports/smtp/smtp.c:
	    Some code rearrangements to better(?) handle stream
	    write errors.

2000-02-02  Matti Aarnio  <mea@mea.tmt.tele.fi>

	* scheduler/mq2.c, transports/mailbox/mailbox.c, transports/sm/sm.c,
	  transports/smtp/smtp.h, transports/smtp/smtptls.c,
	  transports/smtp/smtp.c, transports/smtp/appendlet.c:
	    Turns out the  sfsetfd()  has a undesirable side-effect,
	    which might be turnable off, but...  Namely it does sfsync()
	    on the stream before setting the fd -- we don't want that.


    Most likely core fix is to make the beginning of   ssputc()
    function to be as follows:

....
int
ssputc(SS, ch, fp)
     SmtpState *SS;
     int ch;
     Sfio_t *fp;
{
  if (SS->chunkbuf == NULL) {
    if (sferror(fp)) return EOF;
    if (sfputc(fp, ch) < 0) return EOF;
    return 0;
  }
....


	Additional fix is SFIO  stream abortative dissociation
        function to be used in place of   sfsetfd()  calls in
        the  smtp  transport agent functions.

int zsfsetfd(fp, fd)
     Sfio_t *fp;
     int fd;
{
  /* This is *NOT* the SFIO's sfsetfd() -- we do no sfsync() at any point.. */
  fp->file = fd;
  return fd;
}


> The remote server seems to be a customized Windows NT mailserver,
> and it happens that the company that owns it is our major shareholder
> and most important business partner - any glitch in e-mail communication
> resounds in the server room with an authoritative "do something about
> it" from our CEO.
>
> Does anybody know what might be the problem? I'm pretty sure that's
> something strange happening on the other end of the connection (the
> problem occurs only with this particular site, and only sometimes),
> but that's no excuse for the boss.

     Is this reliable to repeat ?  (I mean with some specific message,
     not that CEO says something :) )
     What appears at the tcp-dump ?

     "Only sometimes" ... I hate heissenbugs....


     Syslog may carry usefull data for the deliveries, too.


> Thanks,
> -- 
> Grzegorz Staniak <gstaniak@zagiel.pl>

-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi