Outlook 2003 delayed emails

[Pete c]

http://www.webuser.co.uk/cgi-bin/fo...=126373&page=2&view=collapsed&sb=5&o=93&part=

i have started outlook 2003 in safe mode, you do this by pressing ctrl and
clicking on outlook, unfortunately no difference, i see that the delaying
of emails is a known issue in outlook 2003, any more ideas of a solution?

many thanks

Peter

found the opm log but no mention of smtp just tx and rx... what do i do
now?

finally managed to find the folder called outlook logging called first
run, is this it, this waht was in the log:

*** Starting First Run (01-13-2005 18:37:52) ***
...HrPreSplashFirstRun called.
...HrPreLogFirstRun called.
...HrPostLogFirstRun called.
..... FCheckFirstRunStatus failed reading machine value "17019"!
...deleting WAB4/UseOutlook because we're using MAPI.
...writing UUID to HKCU.
...setting Primary Client to Outlook.
*** Ending First Run (01-13-2005 18:38:15) ***


ive been to C:\Documents and Settings\<logon name>\Local
Settings\temp\OPMLOG.LOG

but there is no log file there, in outlook it says that logging is
enabled....

"Vanguard" <see_signature> wrote in message
done that and enabled log and exited and then sent a couple of
messages to myself, when they come back will they have the log
embedded in them or will i need to look elsewhere


Outlook's troubleshooting logfile is in %temp%\opmlog.txt; see
http://support.microsoft.com/?id=300479.

Once you enable the troubleshooting log, you have to exit Outlook (it
tells you this). Then make sure there isn't an old one around; if so,
delete it. Then start Outlook. It will probably do a mail poll right
away because of being configured to schedule them. If you did not have
any pending outbound e-mails in your Outbox when you loaded Outlook, send
an e-mail. Exit Outlook.

Don't know what you were looking at in the above logfile output. Maybe
OL2003 changed the format of the output it puts into its logfile. Below
is what I see in OL2002 which, after sending a test e-mail, shows lines
like:

yyyy.mm.dd hh:mm:ss "SMTP: <direction> ...

where direction is "tx" when it transmits to the mail server and "rx"
when it receives data from the mail server. Below is a copy of what I
see when I send an e-mail to an SMTP server with the timestamps removed
and all the encompassing Callback function syntax removed (braced text
are my comments):

SMTP: Finding host
SMTP: Connecting to host
SMTP: Securing connection {I'm using SSL connects}
SMTP: Connected to host
SMTP: <rx> 220 <myISPdomain> - <their comment>
SMTP: [tx] EHLO <myhostname>
SMTP: <rx> 250-<setup status & supported commands> {repeated several
times}
SMTP: Authorizing to server
SMTP: [tx] AUTH LOGIN
{a few more SMTP: lines for handling SSL authentication}
SMTP: <rx> 235 Authentication successful
SMTP: Authorized to host
SMTP: Connected to host
SMTP: [tx] MAIL FROM: <myemailaddr>
SMTP: <rx> 250 ok
SMTP: [tx] RCPT TO: <destinationEmailAddr> {to whom I sent the test
e-mail}
SMTP: <rx> 250 ok; [simple] forward to <destinationEmailAddr>
SMTP: [tx] DATA {my e-mail client transmists the message}
SMTP: <rx> 354 ok
SMTP: [tx] . {to mark the end of the message}
SMTP: <rx> 250 ok

You don't get to see a duplicate of the message data (headers and body)
since that would make the logfile huge. The RCPT TO command specified
who gets my e-mail, the DATA command sends the content of that message to
the mail server, the mail server got it and returned the "354 ok" status,
and my e-mail client said it was done (i.e., no more other messages to
send). Once the "354 ok" status got returned from the DATA command, the
mail server has all the information it needs to deliver the message: who
it goes to and what it is. After that, I have no control over the
message anymore. The comments after the status codes is optional and
variable. What you are looking for when sending a message are the lines:

SMTP: [tx] RCPT TO: <destinationEmailAddr>
Your e-mail client tells the mail server where to deliver the message.
SMTP: <rx> 250
The mail server replies that it got the recipient info.
SMTP: [tx] DATA
You send the content of your message (headers & body).
SMTP: <rx> 354
The mail server say, "Got it okay".
SMTP: [tx] .
You tell the mail server that there is no more data for the message.
SMTP: <rx> 250
Mail server says okay - then it sends whenever it so chooses.

You can use the timestamp on the "SMTP: <rx> 250" line (at the end of
sending the message) to note when your ISP's mail server got your
message. If it then takes 4 hours for it to arrive, you need to trace
backward through the Received headers to see where the delay occurred.

If the OL2003 logfile is significantly different than for OL2002 (which I
have), you'll have to post the logfile so it can be analyzed. Enabling
logging, exit Outlook, delete the old logfile, start Outlook, send a test
e-mail, exit Outlook, and post the logfile.

--
_________________________________________________________________
Post your replies to the newsgroup. Share with others.
E-mail: vanguard_help AT yahoo.com (append "#NEWS#" to Subject)
_________________________________________________________________

 

[Jeff Stephenson [MSFT]]

i have started outlook 2003 in safe mode, you do this by pressing ctrl and
clicking on outlook, unfortunately no difference, i see that the delaying of
emails is a known issue in outlook 2003, any more ideas of a solution?

This is not a "known issue" in Outlook 2003, in the sense that it's
something caused by Outlook. Yes, people using Outlook 2003 have had
problems with mail being delayed, but in every case in which I've seen logs
the message is being delivered promptly to the ISP's server and something
that the ISP is doing is delaying delivery.

Could you turn on logging as Vanguard suggested, then send a message and
post the log?

 

[Vanguard]

Could you turn on logging as Vanguard suggested, then send a message
and
post the log?

That's what I was waiting for. If the log shows the e-mail is getting
accepted by the e-mail client then the e-mail client can do nothing
thereafter to delay the delivery. However, it may be possible that the
e-mail provider is handling e-mails different depending on which e-mail
client is used; however, I see no means for the mail server to even know
what e-mail client is being used. All it sees are a bunch of SMTP
commands, none of which identifies the e-mail client (but maybe it looks
in the headers contained within the DATA of the message).

So Pete has to see if, after composing a new e-mail and trying to send
it using Outlook (so it is in its Outbox), the e-mail is getting
accepted by the mail server on the next mail poll, if there is no
delivery attempt by Outlook to send the message in the next mail poll,
or if a bad status is returned by the authentication, RCPT TO, or DATA
commands (i.e., there is an error in getting the message to the mail
server so there are continual retries).

 

[Jeff Stephenson [MSFT]]

That's what I was waiting for. If the log shows the e-mail is getting
accepted by the e-mail client then the e-mail client can do nothing
thereafter to delay the delivery. However, it may be possible that the
e-mail provider is handling e-mails different depending on which e-mail
client is used; however, I see no means for the mail server to even know
what e-mail client is being used. All it sees are a bunch of SMTP
commands, none of which identifies the e-mail client (but maybe it looks
in the headers contained within the DATA of the message).

So Pete has to see if, after composing a new e-mail and trying to send
it using Outlook (so it is in its Outbox), the e-mail is getting
accepted by the mail server on the next mail poll, if there is no
delivery attempt by Outlook to send the message in the next mail poll,
or if a bad status is returned by the authentication, RCPT TO, or DATA
commands (i.e., there is an error in getting the message to the mail
server so there are continual retries).

Well, Outlook will write headers differently than other clients - for
example the Message-Id format will vary client-to-client, as will a bunch
of X- headers. My guess is that some anti-spam program is holding things
up (though I'd expect it to just accept or reject, rather than delay...).

 

[Pete c]

shall i post the log directly to you. the message goes out from the outbox
immediately on the first poll, just gets delayed at the server thereafter.

pete

 

[Brian Tillman]

shall i post the log directly to you. the message goes out from the
outbox immediately on the first poll, just gets delayed at the server
thereafter.

If it's gone from the client and is sitting in the server, it's not an
Outlook problem and you;ll have to contact the admins of the server.

 

[Pete c]

tried that and they sent the following,

Dear pete,

Thank you for your email.

Unfortunately wanadoo broadband does not support 'Microsoft Outlook'

this program is beyond our technical knowledge. As we can see you are able
to access the emails via 'Outlook Express' this program is not having
problems downloading your emails from the server's, We would advise with
this type of email query that you check over the configuration settings
within 'microsoft outlook', also check the firewall and anti-virus programs.

If you have any further queries then please do not hesitate to get in
contact with us again.

Kind Regards

Kerry.

Wanadoo Technical Support

i would just love to get to the bottom of this, oe works fine, outlook
2002xp works fine, outlook 2003 sends the emails fine but the server for
some reason delays them for hours or days.

whats going on?

Pete

 

[Jeff Stephenson [MSFT]]

Unfortunately wanadoo broadband does not support 'Microsoft Outlook'

What that means is that they won't help you configure Outlook (why is
beyond me, given how many people use it and how easy it would be for them
to help...).

That is irrelevant to this issue, though. The question is their support
for Internet standard email - Outlook has submitted a valid RFC 2822
formatted message to their server, but their server is delaying its
delivery. Why? One place to start with them is the fact that messages
from Outlook 2003 do not contain the Message-Id field, relying on the
server to add that (long explanation there...). Maybe that's causing them
to delay? Can't imagine why, though...

this program is beyond our technical knowledge. As we can see you are able
to access the emails via 'Outlook Express' this program is not having
problems downloading your emails from the server's, We would advise with
this type of email query that you check over the configuration settings
within 'microsoft outlook', also check the firewall and anti-virus programs.

Again, if the message has been submitted to the server and the server has
accepted responsibility for delivery, your Outlook, firewalls, and
anti-virus programs are out of the loop.

 

[Pete c]

http://www.webuser.co.uk/cgi-bin/forums/showthreaded.pl?Cat=&Board=email&Number=153244

I think I'm getting closer to the source of the problem. Whether the bad boy
is Microsoft or Freeserve I'm not sure.

The "Message-ID" line in the e-mail header of test messages I send from
Outlook Express 6 have a string containing my computer name. It is in the
same format whichever ISP and SMTP server I'm sending to, so I conclude OE
is creating it. E-mails sent using Outlook 2003 have "Message-ID"s whose
format depends on the SMTP server being used.

A bit of research using Google has shown that Outlook 2003 does not include
a message ID in e-mails it sends to SMPT servers (see
http://www.terryfrazier.com/1526 or
http://www.tek-tips.com/viewthread.cfm?qid=961988&page=1)

I'm guessing here, but maybe Freeserve's e-mail system puts message it
receives that have no Message-ID into a queue for dealing with later.
Eventually it gets around stamping them with a Message-ID and sending them
on.

 

[Pete c]

Dear Peter,

Thank you for your email.

Wanadoo email accounts that look like this (e-mail address removed) are
what we call a pop3 email account which enables you to access your emails
through Outlook Express. We currently provide extensive support for Outlook
Express, but you are more than welcome to use other email clients that
comply with the standard.

As the problem is when using Outlook 2003 not Outlook Express we suggest you
contact Microsoft Technical Support. Their website is
http://www.microsoft.com/uk/support/

If you have any further queries then please do not hesitate to get in
contact with us again.

Kind Regards

Alan

Wanadoo Technical Support

 

[Pete c]

Sounds possible.....but why doesn't outlook put an id in and why does fs
take so long to invent its own

Dear Peter,

Thank you for your email.

Wanadoo email accounts that look like this (e-mail address removed) are
what we call a pop3 email account which enables you to access your emails
through Outlook Express. We currently provide extensive support for
Outlook Express, but you are more than welcome to use other email clients
that comply with the standard.

As the problem is when using Outlook 2003 not Outlook Express we suggest
you contact Microsoft Technical Support. Their website is
http://www.microsoft.com/uk/support/

If you have any further queries then please do not hesitate to get in
contact with us again.

Kind Regards

Alan

Wanadoo Technical Support

 

[Vanguard]

http://www.webuser.co.uk/cgi-bin/forums/showthreaded.pl?Cat=&Board=email&Number=153244

I think I'm getting closer to the source of the problem. Whether the
bad boy is Microsoft or Freeserve I'm not sure.

The "Message-ID" line in the e-mail header of test messages I send
from Outlook Express 6 have a string containing my computer name. It
is in the same format whichever ISP and SMTP server I'm sending to, so
I conclude OE is creating it. E-mails sent using Outlook 2003 have
"Message-ID"s whose format depends on the SMTP server being used.

A bit of research using Google has shown that Outlook 2003 does not
include a message ID in e-mails it sends to SMPT servers (see
http://www.terryfrazier.com/1526 or
http://www.tek-tips.com/viewthread.cfm?qid=961988&page=1)

I'm guessing here, but maybe Freeserve's e-mail system puts message it
receives that have no Message-ID into a queue for dealing with later.
Eventually it gets around stamping them with a Message-ID and sending
them on.

According to RFC 2822, Internet Message Format, 3.6 Field Definitions,
the Message-ID is optional. It may appear zero or one times. From
3.6.2 Indentification fields, "Though optional, every message SHOULD
have a "Message-ID:" field." "Should" means it is NOT a requirement.
Also, "The message identifier (msg-id) itself MUST be a globally unique
identifier for a message. The generator of the message identifier MUST
guarantee that the msg-id is unique." However, I'm not sure an e-mail
*client* could ever guarantee a globally unique message identifier.

According to RFC 2821, Simple Mail Transfer Protocol, 6.3 Compensating
for Irregularities, "The following changes to a message being processed
MAY be applied when necessary by an originating SMTP server, or one used
as the target of SMTP as an initial posting protocol: Addition of a
message-id field when none appears; (some other changes)." "May" also
does not mean required, so if your e-mail client isn't adding the
Message-ID header then your ISP's SMTP "may" add it.

Since this header is optional, any delay caused by your ISP on detecting
its absence is something unique to their "service". I suppose they
could be batching up all the messages that are missing this header but
that would be just plain stupid because they'll still expend the same
resources later to add the header when they first got your message.
Wanadoo might be doing something extra in trying to ensure their users'
e-mails get out and not rejected by spam filters. Could even be the
receiving SMTP servers use greylisting to ensure that what spews from
Wanadoo isn't spam.

 

[Pete c]

is there any solution to this or simply go back to outlook 2002

 

[Pete c]

a typical case of both parties saying, its nothing to do with us guv....

 

[Vanguard]

is there any solution to this or simply go back to outlook 2002

If your ISP is unwilling to correct their problem of incurring a delay
depending on what they see in the headers included by the e-mail client,
especially OPTIONAL headers, then you can't do anything to guarantee
faster delivery except by trial and error to see what slides past
whatever stupidity they are implementing. I haven't specifically
analyzed the difference in headers between e-mails sent with Outlook and
with Outlook Express.

If it were me, I'd be sending test e-mails to webmail accounts and
noting the delays as shown using the timestamps in the Received headers.
Then I would confront the ISP with those messages that showed their mail
server's Received header (i.e., when they got it from you) and the
receiving mail server's Received header (when they got it from your
ISP's mail server). Then it doesn't matter a gnat's fart what e-mail
client was used because you can show that THEY caused the delay in
delivery. They got it, they delayed it, and there is nothing you can do
to alter their setup.

 

[Jeff Stephenson [MSFT]]

Sounds possible.....but why doesn't outlook put an id in and why does fs
take so long to invent its own

Outlook 2003 does not put the Message-Id in because of customer complaints
that the Outlook Message-Id field revealed too much information about the
computer that generated it (there are those that care a lot about revealing
their machine names, etc.). The complaints came in near the end of the
beta testing of Outlook 2003 and we didn't really have the time to come up
with a way of both hidding personally identifiable information and
satisfying the uniqueness requirements placed on the field by RFC 2822.
So, since the field is optional (as Vanguard pointed out), we just dropped
it and let the ISP write it.

Why Freeserve's server takes so long to send a message without the
Message-Id is beyond me - it's a simple thing to generate (they don't have
to worry about identifiable information, since their server names are
already required to be written to the name in the Received: field). My
guess is some anti-spam software is somehow delaying things.

As to what to do, I'd take Vanguard's approach and present them with a
combination of logs from your machine that show when the message was
accepted by their server and the headers from the delivered message that
show when it was delivered. The problem is on their side, not with
Outlook.

 

[Pete c]

jimbaker replied to your post at the site: .

http://www.webuser.co.uk/cgi-bin/forums/showthreaded.pl?Cat=&Board=email&Number=154832

Now had a reply from Wanadoo. It's amazing that they have to check all these
e-mails manually!

I currently seeing if running a local SMTP server on my PC & relaying
messages through that will add a message ID that Freeserve likes.

Reply from Wanadoo...

------------------------------------------

Dear Jim,

Thank you for your email.

Unfortunately, we do not specifically support Outlook 2003, only Outlook
Express. We will certainly pass your comments on with regards a new help
article to be implemented in the future.

You are correct to identify the message ID as a source of the problems.

Emails without message IDs get stuck at our server, and a manual process is
undertaken to clear these. This is why you are experiencing the delays. This
process is to stop 'spoofing', whereby users sending unsolicited mail hide
the true origin to cover their tracks. These emails are then manually
checked for their validity before being forwarded to the recipient.

As we do not support Outlook 2003, I would suggest that you contact
Microsoft to see if their is a resolution to this.

If you have any further queries then please do not hesitate to get in
contact with us again.

Kind Regards

Chris

Wanadoo Customer Action Team

 

[Jeff Stephenson [MSFT]]

Now had a reply from Wanadoo. It's amazing that they have to check all these
e-mails manually!

That's totally bizarre!

You are correct to identify the message ID as a source of the problems.

Emails without message IDs get stuck at our server, and a manual process is
undertaken to clear these. This is why you are experiencing the delays. This
process is to stop 'spoofing', whereby users sending unsolicited mail hide
the true origin to cover their tracks. These emails are then manually
checked for their validity before being forwarded to the recipient.

So if I want to spoof, I just use a Message-Id of <[email protected]> and
they'll be happy? Wow, that's security ;-). What they need is a new
server, that can add a Message-Id per RFC 2822...

 

[Vanguard]

So if I want to spoof, I just use a Message-Id of <[email protected]> and
they'll be happy? Wow, that's security ;-). What they need is a new
server, that can add a Message-Id per RFC 2822...

Yeah, I just thought of that after submitting my prior post. All you
would have to do is insert your own "Message-ID:
<somestring@somedomain>" string into your data. So how does that stop
spoofing? I could enter "Message-ID:
<[email protected]>" and be you based on
their stupidity. It's part of the user's *data* sent in the DATA
command, so the user can put anything he wants in the header portion of
their data since those headers are NOT used in routing the message.
And, of course, all those trojanized PC running mailer daemons are
really going to comply with Wanadoo's requirements.

It seems easy enough to force Wanadoo to be RFC complaint with SMTP
standards. Get a group of enthused Wanadoo customers that want to use
Outlook (or any other e-mail client that doesn't insert a Message-ID
header) but don't want to incur ridiculous delays due to manual
intervention by spewing as many of these e-mails as possible. This will
force Wanadoo to expend even more manpower to manually handle all these
e-mails and eventually they might decide it isn't worth their time to
infuriate their customers. "I have to move all the furniture to the
other side of the room to move the rug to get to the floor safe." So
make them do that often enough and eventually they'll learn to leave the
furniture on the other side of the room. Even fleas with their tiny
brains will eventually figure out to stop jumping so high to stop
hitting their heads against the lid of the jar (afterwhich you can leave
off the lid and they won't jump out).

Of course, retaliation always has negatives so trying to educate the
boobs at Wanadoo is a more appropriate method to get them to change.

 

[Vanguard]

...

You are correct to identify the message ID as a source of the
problems.

Emails without message IDs get stuck at our server, and a manual
process is undertaken to clear these. This is why you are experiencing
the delays. This process is to stop 'spoofing', whereby users sending
unsolicited mail hide the true origin to cover their tracks. These
emails are then manually checked for their validity before being
forwarded to the recipient.
...

Then reply back to Wanadoo that they are VIOLATING the RFC 2821 and RFC
2822 standards for SMTP. The Message-ID headers is ***OPTIONAL***. The
e-mail client (MUA) does NOT have to provide one. According to RFC
2822, Internet Message Format, 3.6 Field Definitions, the MUA may insert
the Message-ID header zero or one times. That means this header is
optional (as it may appear zero times) and, if specified, can appear a
maximum of once. According to RFC 2821, Simple Mail Transfer Protocol,
6.3 Compensating for Irregularities, the mail server (MTA) can add a
Message-ID header *if* it wants to add the header but it can add this
header ONLY if it is missing in the content transferred during the DATA
command to their SMTP server.

So is is NOT a requirement that the MUA (mail user agent) include the
Message-ID header. If and only if it is missing in the content
transferred in the DATA command from the MUA, and only if the MTA (mail
transfer agent) deems that this header should be present, the MTA can
add this header. Tell Wanadoo their mail server is ****ed up. They are
enforcing their own non-compliant policies. That's their choice but
then they need to announce that fact in the help web pages, in their
setup help, notify their tech support reps, and also realize that they
are barring MANY e-mail clients from using their e-mail service or
causing problems with its use. Fact is, it seems users could retaliate
by spewing as many e-mails as they could that do not include the
Message-ID header to force Wanadoo to expend even greater resources in
manually handling these e-mails to the point that they wise up and
decide to make the mail servers compliant with the RFC standards. Make
them work even harder at enforcing their non-compliant and
personal-choice policies.

By the way, if the MUA (mail user agent) is generating the unique
identifier string in the Message-ID header then the mail server cannot
ever check its validity since the mail server wasn't the one that
generated the unique string identifier. Their mail server will somehow
query my e-mail client that it was the one that generated the unique
identifier string? Yeah, sure, uh huh. RFC 2822, Internet Message
Format, says:

Section 3.6.4 Identification fields:
"The Message-ID field provides a unique message identifier that refers
to a particular version of a particular message. The uniqueness of the
message identifier is guaranteed by the host that generates it."

Since Wanadoo isn't generating the unique identifier, and instead your
e-mail client generates that string, there is no way anyone at Wanadoo
can verify whether or not it is a valid identifier. They only part of
the string that Wanadoo can check is the domain portion after the
at-character. However, while the unique identifier contains the domain
that could be the internal domain of the user rather than of an external
ISP. The syntax for the Message-ID header's msg-id value is:

message-id = "Message-ID:" msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-right = dot-atom-text / no-fold-literal / obs-id-right

(CFWS is folding white space). It does not dictate that the id-right
token must contain a domain (except in the obsolete version) but it
seems the de facto standard that id-right contains the domain. Since
you are running your e-mail client on your computer which may be within
your own domain, there is no guarantee that the domain used by the
e-mail client will have anything related to some external domain (i.e.,
your ISP) and obviously your internal domain is not likely to be the
same as the external domain for your ISP. If Wanadoo wants to ensure
the Message-ID is distintive to their e-mail accounts then Wanadoo needs
to add the Message-ID header itself to every outbound e-mail (and
discard any that was added by the e-mail client).