Sendmail Version 8.13.7+Sun

I'm having a problem with connection caching (I think). The
symptom is that when I have several messages in the queue
bound for a particular domain, only one message gets
delivered per queue run. The MTA at the other end is a
"home-built" Java application that isn't behaving well, but I
would expect sendmail to be smart enough to deal with
it.

The SMTP conversation looks like this,

S: 220 SMSC Service ready
C: EHLO smsc1.example.com
S: 250 SMSC
C: MAIL From:<sli@example.com>
S: 250 OK
C: RCPT To:<5551234567@msg.example.com>
S: 250 OK
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: [message]
C: .
S: 250 Message accepted for delivery
C: RSET
S: 221 SMSC closing connection
C: MAIL From:<digit@example.org>
<connection closes>

That is, the remote MTA (not sendmail) is responding to the
RSET with a 221, but sendmail (the client end, a queue runner)
tries a MAIL FROM anyway. The result is that sendmail dequeues
the first message, but stops processing the queue for this domain
with a "reply: read error" for the message that was interrupted, and
defers the remainder to that domain.

>From how I understand connection caching, sendmail should be
able to deal with this. From op.txt,

When trying to open a connection the cache is
first searched. If an open connection is found, it is
probed to see if it is still active by sending a RSET
command. It is not an error if this fails; instead,
the connection is closed and reopened.

Shouldn't sendmail be smart enough to understand the 221
to its RSET even though it is well out of the SMTP spec?

Anyway, I think the ForkEachJob option should workaround this
problem. I just thought that sendmail might be smart enough to
deal with a remote MTA that isn't smart enough to handle only
one message per session. Is sendmail supposed to be able to
deal with this?

"yheffen@gmail.com" <yheffen@gmail.com> writes:

> Sendmail Version 8.13.7+Sun
>
> I'm having a problem with connection caching (I think). The
> symptom is that when I have several messages in the queue
> bound for a particular domain, only one message gets
> delivered per queue run. The MTA at the other end is a
> "home-built" Java application that isn't behaving well, but I
> would expect sendmail to be smart enough to deal with
> it.
>
> The SMTP conversation looks like this,
>
> S: 220 SMSC Service ready
> C: EHLO smsc1.example.com
> S: 250 SMSC
> C: MAIL From:<sli@example.com>
> S: 250 OK
> C: RCPT To:<5551234567@msg.example.com>
> S: 250 OK
> C: DATA
> S: 354 Enter mail, end with "." on a line by itself
> C: [message]
> C: .
> S: 250 Message accepted for delivery
> C: RSET
> S: 221 SMSC closing connection
> C: MAIL From:<digit@example.org>
> <connection closes>
>
> That is, the remote MTA (not sendmail) is responding to the
> RSET with a 221, but sendmail (the client end, a queue runner)
> tries a MAIL FROM anyway. The result is that sendmail dequeues
> the first message, but stops processing the queue for this domain
> with a "reply: read error" for the message that was interrupted, and
> defers the remainder to that domain.
>
>>From how I understand connection caching, sendmail should be
> able to deal with this. From op.txt,
>
> When trying to open a connection the cache is
> first searched. If an open connection is found, it is
> probed to see if it is still active by sending a RSET
> command. It is not an error if this fails; instead,
> the connection is closed and reopened.
>
> Shouldn't sendmail be smart enough to understand the 221
> to its RSET even though it is well out of the SMTP spec?

Sendmail gets 2?? reply to RSET.
Sendmail considers it to be *aknowlegement* of RSET command but the
remote side seems to treat RSET like QUIT (*WRONG*).

It seems that remote side implementation of ESMTP is *broken*.

> Anyway, I think the ForkEachJob option should workaround this
> problem. I just thought that sendmail might be smart enough to
> deal with a remote MTA that isn't smart enough to handle only
> one message per session. Is sendmail supposed to be able to
> deal with this?

You may create custom variant of smtp mailer sending one message per one
SMTP connection and slect it via mailertable to deal with this
*brokeness of the other side*.

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Before You Ask: http://anfi.homeunix.net/sendmail/B4UAsk-Sendmail.html
http://anfi.homeunix.net/sendmail/

Andrzej Adam Filip wrote:
> "yheffen@gmail.com" <yheffen@gmail.com> writes:
>
> > Sendmail Version 8.13.7+Sun
> >
> > I'm having a problem with connection caching (I think). The
> > symptom is that when I have several messages in the queue
> > bound for a particular domain, only one message gets
> > delivered per queue run. The MTA at the other end is a
> > "home-built" Java application that isn't behaving well, but I
> > would expect sendmail to be smart enough to deal with
> > it.
> >
> > The SMTP conversation looks like this,
> >
> > S: 220 SMSC Service ready
> > C: EHLO smsc1.example.com
> > S: 250 SMSC
> > C: MAIL From:<sli@example.com>
> > S: 250 OK
> > C: RCPT To:<5551234567@msg.example.com>
> > S: 250 OK
> > C: DATA
> > S: 354 Enter mail, end with "." on a line by itself
> > C: [message]
> > C: .
> > S: 250 Message accepted for delivery
> > C: RSET
> > S: 221 SMSC closing connection
> > C: MAIL From:<digit@example.org>
> > <connection closes>
> >
> > That is, the remote MTA (not sendmail) is responding to the
> > RSET with a 221, but sendmail (the client end, a queue runner)
> > tries a MAIL FROM anyway. The result is that sendmail dequeues
> > the first message, but stops processing the queue for this domain
> > with a "reply: read error" for the message that was interrupted, and
> > defers the remainder to that domain.
> >
> >>From how I understand connection caching, sendmail should be
> > able to deal with this. From op.txt,
> >
> > When trying to open a connection the cache is
> > first searched. If an open connection is found, it is
> > probed to see if it is still active by sending a RSET
> > command. It is not an error if this fails; instead,
> > the connection is closed and reopened.
> >
> > Shouldn't sendmail be smart enough to understand the 221
> > to its RSET even though it is well out of the SMTP spec?
>
> Sendmail gets 2?? reply to RSET.
> Sendmail considers it to be *aknowlegement* of RSET command but the
> remote side seems to treat RSET like QUIT (*WRONG*).
>
> It seems that remote side implementation of ESMTP is *broken*.

Yes. I realize that the remote end is behaving badly. The only
correct answer to RSET is supposed to be 250 with the MTA
in fresh state as if it had just receieved the HELO.

However, I think it is also a problem that sendmail treats a
221 like a 250. It shouldn't just be looking for 2**, if that is
indeed how the code works (haven't dug into the src to check).
A 221 always means that the server is about to close the channel.
IMHO, an unexpected 221 should be treated more like a 421.

> > Anyway, I think the ForkEachJob option should workaround this
> > problem. I just thought that sendmail might be smart enough to
> > deal with a remote MTA that isn't smart enough to handle only
> > one message per session. Is sendmail supposed to be able to
> > deal with this?
>
> You may create custom variant of smtp mailer sending one message per one
> SMTP connection and slect it via mailertable to deal with this
> *brokeness of the other side*.

I looked for mailer options (this remote MTA already has a special
mailer devoted to it for other reasons) that could force one message
per connection, but didn't find a mailer flag that seemed to cover
this.
How might I specify the "one message per connection" in a mailer
definition?

"yheffen@gmail.com" <yheffen@gmail.com> writes:

> Andrzej Adam Filip wrote:
>> "yheffen@gmail.com" <yheffen@gmail.com> writes:
>>
>> > Sendmail Version 8.13.7+Sun
>> >
>> > I'm having a problem with connection caching (I think). The
>> > symptom is that when I have several messages in the queue
>> > bound for a particular domain, only one message gets
>> > delivered per queue run. The MTA at the other end is a
>> > "home-built" Java application that isn't behaving well, but I
>> > would expect sendmail to be smart enough to deal with
>> > it.
>> >
>> > The SMTP conversation looks like this,
>> >
>> > S: 220 SMSC Service ready
>> > C: EHLO smsc1.example.com
>> > S: 250 SMSC
>> > C: MAIL From:<sli@example.com>
>> > S: 250 OK
>> > C: RCPT To:<5551234567@msg.example.com>
>> > S: 250 OK
>> > C: DATA
>> > S: 354 Enter mail, end with "." on a line by itself
>> > C: [message]
>> > C: .
>> > S: 250 Message accepted for delivery
>> > C: RSET
>> > S: 221 SMSC closing connection
>> > C: MAIL From:<digit@example.org>
>> > <connection closes>
>> >
>> > That is, the remote MTA (not sendmail) is responding to the
>> > RSET with a 221, but sendmail (the client end, a queue runner)
>> > tries a MAIL FROM anyway. The result is that sendmail dequeues
>> > the first message, but stops processing the queue for this domain
>> > with a "reply: read error" for the message that was interrupted, and
>> > defers the remainder to that domain.
>> >
>> >>From how I understand connection caching, sendmail should be
>> > able to deal with this. From op.txt,
>> >
>> > When trying to open a connection the cache is
>> > first searched. If an open connection is found, it is
>> > probed to see if it is still active by sending a RSET
>> > command. It is not an error if this fails; instead,
>> > the connection is closed and reopened.
>> >
>> > Shouldn't sendmail be smart enough to understand the 221
>> > to its RSET even though it is well out of the SMTP spec?
>>
>> Sendmail gets 2?? reply to RSET.
>> Sendmail considers it to be *aknowlegement* of RSET command but the
>> remote side seems to treat RSET like QUIT (*WRONG*).
>>
>> It seems that remote side implementation of ESMTP is *broken*.
>
> Yes. I realize that the remote end is behaving badly. The only
> correct answer to RSET is supposed to be 250 with the MTA
> in fresh state as if it had just receieved the HELO.
>
> However, I think it is also a problem that sendmail treats a
> 221 like a 250. It shouldn't just be looking for 2**, if that is
> indeed how the code works (haven't dug into the src to check).
> A 221 always means that the server is about to close the channel.
> IMHO, an unexpected 221 should be treated more like a 421.

You can suggest changing sendmail behavior the way you suggested to
sendmail.org http://www.sendmail.org/misc/email-addresses.php

>> > Anyway, I think the ForkEachJob option should workaround this
>> > problem. I just thought that sendmail might be smart enough to
>> > deal with a remote MTA that isn't smart enough to handle only
>> > one message per session. Is sendmail supposed to be able to
>> > deal with this?
>>
>> You may create custom variant of smtp mailer sending one message per one
>> SMTP connection and slect it via mailertable to deal with this
>> *brokeness of the other side*.
>
> I looked for mailer options (this remote MTA already has a special
> mailer devoted to it for other reasons) that could force one message
> per connection, but didn't find a mailer flag that seemed to cover
> this.
> How might I specify the "one message per connection" in a mailer
> definition?

It is controlled by "m=..." mailer option added in sendmail-8.10.

You can set it in *.mc file by defining SMTP_MAILER_MAXMSGS for smtp,
smtp8, esmtp, dsmtp mailers and by defining RELAY_MAILER_MAXMSGS for
relay mailer e.g.
define(`RELAY_MAILER_MAXMSGS',`1')

--
[pl2en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Before You Ask: http://anfi.homeunix.net/sendmail/B4UAsk-Sendmail.html
http://anfi.homeunix.net/sendmail/