Messages stuck in the queue - Inetserver

"Rel87" <Rel87@discussions.microsoft.com> wrote in message
news:76C8F526-FC73-4742-ABCB-98A5D12708ED@microsoft.com...
>I have messages stuck in the queue (C:\Inetpub\mailroot\Queue), where can I
> see to whom this messages are to be delivered? (the log file doesn't gives
> me
> the info, just the email addresses that where delivered or not)
>
> Thanks in advance,
> Ariel

You can use a text editor like Notepad or TextPad (http://www.textpad.com -
free & MUCH better!) to open the files and see who the intended recipient
is.

> I have messages stuck in the queue (C:\Inetpub\mailroot\Queue), where
> can I see to whom this messages are to be delivered? (the log file
> doesn't gives me the info, just the email addresses that where delivered
> or not)

Please read that aloud to yourself: "Where can I see to whom... messages
are to be delivered? The log file [gives me] just the email addresses
that were delivered or not."

That's probably not the best way to ask your question.

What you mean is: "The log file only shows me the data sent/received
during TCP/IP connections that could successfully be made with remote
servers. I want to see all the recipient info for messages left in the
queue, including those recipients for whom a TCP/IP connection could not
even be established to the domain's MX or A record."

You can view the information you want by examining the :PROPERTIES
alternate data stream of .EML messages in the queue. This is a binary
file (although the .EML's primary data stream is plain-text).

--Sandy

> You can use a text editor like Notepad or TextPad
> (http://www.textpad.com - free & MUCH better!) to open the files and
> see who the intended recipient is.

Ron -- I'm not just trying to correct you at every turn here, rather
trying to prevent misinfo in the ng archives if I can -- but this is
incorrect.

The primary data stream of the file is the RFC822 message headers/body
ready to be sent as-is to the remote server. This will NOT include
envelope sender + recipient information (which is what the OP wants)
in common legitimate cases (mailing lists, BCCs), and furthermore is
readily forged.

The :PROPERTIES and :PROPERTIES-LIVE streams are where the actual
routing information is stored.

--Sandy

"Sanford Whiteman" <swhitemanlistens-software@cypressintegrated.com> wrote
in message newsp.tuwsyaig6c17zw@gw02.broadleaf.local...
>> You can use a text editor like Notepad or TextPad
>> (http://www.textpad.com - free & MUCH better!) to open the files and
>> see who the intended recipient is.
>
> Ron -- I'm not just trying to correct you at every turn here, rather
> trying to prevent misinfo in the ng archives if I can

Don't worry about it. I agree with you it's best if there is good info
available ;-)

> -- but this is
> incorrect.
>
> The primary data stream of the file is the RFC822 message headers/body
> ready to be sent as-is to the remote server. This will NOT include
> envelope sender + recipient information (which is what the OP wants)
> in common legitimate cases (mailing lists, BCCs), and furthermore is
> readily forged.
>
> The :PROPERTIES and :PROPERTIES-LIVE streams are where the actual
> routing information is stored.
>
> --Sandy

Hmmm... I could have sworn I've used that technique before but maybe I was
thinking of messages in the Badmail folder.

> Hmmm... I could have sworn I've used that technique before but maybe I
> was thinking of messages in the Badmail folder.

You probably were. Badmail gets split into separate plain-text messages
for each queue object.

--Sandy

Thanks, Sandy, that's exactly what I was looking for. Please excuse me for my
English, it is not my native language.
As you correctly guessed, it's a mailing list with BCC, so the
destination(s) doesn't appear in the EML.
I checked the :PROPERTIES data stream, and here are all the original
recipients, unfortunately it doesn't give a clear indication to which
recipients the message was delivered and to which not, must be somewhere in
the binary content in the file, I will have to do a correlation with the logs.

The problem is that I am having emails delivered many times to some of the
recipients, probably (I thought) because of slow connections with some hosts.
I checked the log file and found that effectively there was some breaks to
the SMTP dialogs that could lead to the repetitions, but I found too that
sometimes the email was delivered completely to some recipients, with
presence of the >QUIT <221 Closing connection. dialog, but anyway later the
messages to these recipients where delivered again, as if the SMTP server did
not deleted the email address from the recipients list, maybe because there
where other recipients in the same .EML that where not delivered? I don't
believe this is a bug or something in the IIS SMTP server, or I'm missing
something?
Finally I moved the messages from Queue to other folder so they will not be
delivered again, but I don't know for sure to which recipients it was
delivered, without a deep revision of the log.
I will adjust the SMTP parameters so not so many emails are delivered at the
same time, and limit the conections for each domain to 1, hope this fix the
problem, if not I will have to change to another SMTP program .
Any thoughts?

Thanks again,
Ariel

"Sanford Whiteman" wrote:

> > I have messages stuck in the queue (C:\Inetpub\mailroot\Queue), where
> > can I see to whom this messages are to be delivered? (the log file
> > doesn't gives me the info, just the email addresses that where delivered
> > or not)
>
> Please read that aloud to yourself: "Where can I see to whom... messages
> are to be delivered? The log file [gives me] just the email addresses
> that were delivered or not."
>
> That's probably not the best way to ask your question.
>
> What you mean is: "The log file only shows me the data sent/received
> during TCP/IP connections that could successfully be made with remote
> servers. I want to see all the recipient info for messages left in the
> queue, including those recipients for whom a TCP/IP connection could not
> even be established to the domain's MX or A record."
>
> You can view the information you want by examining the :PROPERTIES
> alternate data stream of .EML messages in the queue. This is a binary
> file (although the .EML's primary data stream is plain-text).
>
> --Sandy
>
>

> I checked the :PROPERTIES data stream, and here are all the original
> recipients, unfortunately it doesn't give a clear indication to
> which recipients the message was delivered and to which not, must be
> somewhere in the binary content in the file, I will have to do a
> correlation with the logs.

Yes, getting the most recent delivery result is tougher; I haven't
deciphered the binary format to that extent.

You'll have to do more log correlation.

> ...the SMTP server did not deleted the email address from the
> recipients list, maybe because there where other recipients in the
> same .EML that where not delivered?

Certainly, that would be (as you note) a giant bug! I doubt that's
what's happening. I imagine you've already checked to make sure the
same recipient did not get sent to multiple times and thus appears in
multiple queue objects?

Other than that, there is one rare-ish situation which can cause
non-delivery even when a QUIT command appears to be sent: some
malfunctioning MTAs disconnect after the trailing "." is sent. In
other words, they disconnect the socket while the QUIT data is still
outbound. If the socket is dropped "dirty" like that, the sending
server may retry. But that is, as I said, rare and should not occur in
any quantity (unless perhaps you have local network issues which are
accelerating its frequency?).

> I will adjust the SMTP parameters so not so many emails are
> delivered at the same time, and limit the conections for each domain
> to 1, hope this fix the problem...

That can only help your situation, certainly. It is possible that you
are saturating your line. I don't know about the volume of messages
you are sending and the speed of your upstream, but it is remarkably
easy to saturate a T1 with an unrestricted, multithreaded mail blast.
The more dropped packets you have, the more IIS' simple
application-level logs will fail to reflect what is really happening
on the wire. You should get a packet sniffer on there and check for
such errors.

I can say with surety that IIS SMTP is an extremely powerful MTA that
can send millions of messages a day on proper hardware, so I doubt
your problem starts within IIS.

--Sandy

"Sanford Whiteman" wrote:

> Certainly, that would be (as you note) a giant bug! I doubt that's
> what's happening. I imagine you've already checked to make sure the
> same recipient did not get sent to multiple times and thus appears in
> multiple queue objects?
Yes, I've already checked that.

> Other than that, there is one rare-ish situation which can cause
> non-delivery even when a QUIT command appears to be sent: some
> malfunctioning MTAs disconnect after the trailing "." is sent. In
> other words, they disconnect the socket while the QUIT data is still
> outbound. If the socket is dropped "dirty" like that, the sending
> server may retry. But that is, as I said, rare and should not occur in
> any quantity (unless perhaps you have local network issues which are
> accelerating its frequency?).
This seems not to be the case, since I get the "221 Closing connection."
answer from the remote server.

> That can only help your situation, certainly. It is possible that you
> are saturating your line. I don't know about the volume of messages
> you are sending and the speed of your upstream, but it is remarkably
> easy to saturate a T1 with an unrestricted, multithreaded mail blast.
> The more dropped packets you have, the more IIS' simple
> application-level logs will fail to reflect what is really happening
> on the wire. You should get a packet sniffer on there and check for
> such errors.

Thanks for all the recomendations, according to my calculations the upstream
pipe should be enough, but we have some slowness with some destinations that
by coincidence are the destination of a lot of the emails in the mailing.
Will wait for the next mailing (it's only every 2 months, so I don't have
many chances to study the matter, but the receivers are very important
persons in my organization) to see if the restrictions in the SMTP properties
I've put does the magic.

Thanks again,
Ariel

"Ron Hinds" wrote:

>
> You can use a text editor like Notepad or TextPad (http://www.textpad.com -
> free & MUCH better!) to open the files and see who the intended recipient
> is.
Just a quick note, Textpad is an excellent tool, but it is not free, it's
something like shareware or "try before you buy". But if you can live with
the nag screen and the moral pain, it's ok this way