[quote user="Dirty Harry"]
I am still receiving admonishments from all those folks on my Dlist whom I have mail bombed. I kept trying to resend the message cuz I thought it was not sent ala timeout. It was bounced back to me as NOT sent and was even held over in the outbox queue. Well, that was a lie since everyone received the message in fine form..........several times. (ugh) [:S]
[/quote]
The way SMTP works, the sending client sends all the recipient addresses, then after they have all been processed (accepted or explicitly rejected), it sends the message data. It's not possible for the message to be sent unless all the recipient addresses have all been processed by the relaying server. Furthernore, the SMTP protocol definition, RFC2821, says that if a client program receives an unexpected connection-related error, it must act as if a 400-series error had occurred - which will cause it to resubmit the message:
---------- cut here ------------
SMTP clients that experience a connection close, reset, or other
communications failure due to circumstances not under their control
(in violation of the intent of this specification but sometimes
unavoidable) SHOULD, to maintain the robustness of the mail system,
treat the mail transaction as if a 451 response had been received and
act accordingly.
---------- cut here ------------
So, if the relaying SMTP server is getting a failure any time up to the point where its final message is accepted by the client, then it should *not* be sending the message - it should be expecting the client software to resend it (as Pegasus Mail is apparently doing).
It sounds to me as though your ISP's server is accepting the mail for relaying and then not reacting properly to a connection error encountered sometime after the DATA command, sending the message on anyway instead of failing it. This will result in multiple copies of the message going out, because Pegasus Mail will - correctly - act as if a "temporary failure - please retry" response had been received and will subsequently retransmit the message.
I admit that I don't have the entire information package here, so I'm scrambling a bit and may be missing something, but what you're describing should not be possible in a situation where both sides of the connection are following the rules (and needless to say, I'm pretty confident that my code follows those rules).
-- David --
[quote user="Dirty Harry"]<p>I am still&nbsp;receiving admonishments from all those folks on my Dlist&nbsp;whom I&nbsp;have mail bombed.&nbsp; I kept trying to resend the message cuz I thought&nbsp;it was&nbsp;not sent ala timeout.&nbsp;&nbsp;It was&nbsp;bounced back to me&nbsp;as NOT sent and was even held over in the outbox queue.&nbsp; Well, that was a lie since everyone received the message in fine form..........several times.&nbsp;(ugh)&nbsp; [:S]</p><p>[/quote]
The way SMTP works, the sending client sends all the recipient addresses, then after they have all been processed (accepted or explicitly rejected), it sends the message data. It's not possible for the message to be sent unless all the recipient addresses have all been processed by the relaying server. Furthernore, the SMTP protocol definition, RFC2821, says that if a client program receives an unexpected connection-related error, it must act as if a 400-series error had occurred - which will cause it to resubmit the message:
---------- cut here ------------
&nbsp;&nbsp; SMTP clients that experience a connection close, reset, or other
&nbsp;&nbsp; communications failure due to circumstances not under their control
&nbsp;&nbsp; (in violation of the intent of this specification but sometimes
&nbsp;&nbsp; unavoidable) SHOULD, to maintain the robustness of the mail system,
&nbsp;&nbsp; treat the mail transaction as if a 451 response had been received and
&nbsp;&nbsp; act accordingly.
---------- cut here ------------
So, if the relaying SMTP server is getting a failure any time up to the point where its final message is accepted by the client, then it should *not* be sending the message - it should be expecting the client software to resend it (as Pegasus Mail is apparently doing).
It sounds to me as though your ISP's server is accepting the mail for relaying and then not reacting properly to a connection error encountered sometime after the DATA command, sending the message on anyway instead of failing it. This will result in multiple copies of the message going out, because Pegasus Mail will - correctly - act as if a "temporary failure - please retry" response had been received and will subsequently retransmit the message.
I admit that I don't have the entire information package here, so I'm scrambling a bit and may be missing something, but what you're describing should not be possible in a situation where both sides of the connection are following the rules (and needless to say, I'm pretty confident that my code follows those rules).
-- David --
</p>
