 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Outlook / New Users / January 2005Outlook 2003 delayed emails
i am currently running outlook 2003, winxp sp2, sending mail from outlook takes hours for the mail to be delivered, sending from oe is immediate. i have disabled the firewall and antivirus software, the isp is wannadoo, what else can i do. Peter Did you also disable the virusscanner integration with Outlook? Does the same happen when you use Outlook in safe mode?  SignatureRobert Sparnaaij [MVP-Outlook] www.howto-outlook.com Tips of the month: -What do the Outlook Icons Mean? -Create an Office 2003 CD slipstreamed with Service Pack 1 ----- >i am currently running outlook 2003, winxp sp2, sending mail from outlook >takes hours for the mail to be delivered, sending from oe is immediate. i >have disabled the firewall and antivirus software, the isp is wannadoo, >what else can i do. > > Peter thanks robert, i uninstalled avg7 completely, is there something else that i should do, apologies for the multiposting Peter > Did you also disable the virusscanner integration with Outlook? Does the > same happen when you use Outlook in safe mode? [quoted text clipped - 5 lines] >> >> Peter AVG again... See if they have got some updates that addresses this issue. Otherwise disable they Outlook integration of the virusscanner. The on access scanner is sufficient in case you accidentally open a virus infected e-mail (most attachments that could contain a virus are blocked by default by Outlook anyway). SignatureRobert Sparnaaij [MVP-Outlook] www.howto-outlook.com Tips of the month: -What do the Outlook Icons Mean? -Create an Office 2003 CD slipstreamed with Service Pack 1 ----- > thanks robert, i uninstalled avg7 completely, is there something else that > i should do, apologies for the multiposting [quoted text clipped - 10 lines] >>> >>> Peter no, avg was completely uninstalled... > AVG again... See if they have got some updates that addresses this issue. > Otherwise disable they Outlook integration of the virusscanner. The on [quoted text clipped - 16 lines] >>>> >>>> Peter You mean the issue still existed after you uninstalled AVG? Do you have some other mail scanning or synchronisation software installed? Disable those and try again. Also check to see if things are working correctly in safe mode; Start-> Run; "path to outlook.exe" /safe SignatureRobert Sparnaaij [MVP-Outlook] www.howto-outlook.com Tips of the month: -What do the Outlook Icons Mean? -Create an Office 2003 CD slipstreamed with Service Pack 1 ----- > no, avg was completely uninstalled... > [quoted text clipped - 18 lines] >>>>> >>>>> Peter issue still exists after uninsatlling avg, no other sync software running, finding difficulty finding the correct path to outlook.exe to get it to run in safe mode. > You mean the issue still existed after you uninstalled AVG? Do you have > some other mail scanning or synchronisation software installed? Disable [quoted text clipped - 24 lines] >>>>>> >>>>>> Peter > issue still exists after uninsatlling avg, no other sync software > running, finding difficulty finding the correct path to outlook.exe to > get it to run in safe mode. Do a search on the file. It is probably under "C:\Program Files\Microsoft Office\Office11\". You could right-click on the shortcut to load Outlook in your Start menu to look at its properties to see the path to it (and you could then just copy that to paste into Start -> Run). >i am currently running outlook 2003, winxp sp2, sending mail from >outlook takes hours for the mail to be delivered, sending from oe is >immediate. i have disabled the firewall and antivirus software, the isp >is wannadoo, what else can i do. > > Peter If you are connecting Outlook to an SMTP server, have you enabled the troubleshooting log to see that the SMTP server is getting the e-mail when you attempt to send? Do you see the RCPT TO command (for the recipient) following by the DATA command which gets a good status returned? Once the mail server has it, you don't have any control over when it gets delivered. What is the scheduled interval for the mail poll? Do you have a rule to delay delivery? Or are you connecting to Exchange? If so, did you configure Outlook for delayed delivery? Signature_________________________________________________________________ Post your replies to the newsgroup. Share with others. E-mail: vanguard_help AT yahoo.com (append "#NEWS#" to Subject) _________________________________________________________________ thanks guys, i seem to have solved it, changed my out going server to requires authetication on, use the same settings as my incoming mail server and bingo, works a treat, also with avg7 fully installed. kind regards pete >>i am currently running outlook 2003, winxp sp2, sending mail from outlook >>takes hours for the mail to be delivered, sending from oe is immediate. i [quoted text clipped - 15 lines] > Or are you connecting to Exchange? If so, did you configure Outlook for > delayed delivery? spoke too soon, again! two went through instantly then nothing more, oe still gets through staright away. now trying the other suggested solutions > thanks guys, > [quoted text clipped - 25 lines] >> Or are you connecting to Exchange? If so, did you configure Outlook for >> delayed delivery? how do i enable the troubleshooting log, i can see wether the mail is getting to the smtp server as i can acess it on the web, it is not, mail poll is set to 1 minute, no rule for delayed delivery. not using exchange. > If you are connecting Outlook to an SMTP server, have you enabled the > troubleshooting log to see that the SMTP server is getting the e-mail when [quoted text clipped - 8 lines] > Or are you connecting to Exchange? If so, did you configure Outlook for > delayed delivery? > how do i enable the troubleshooting log, i can see wether the mail is > getting to the smtp server as i can acess it on the web, it is not, > mail poll is set to 1 minute, no rule for delayed delivery. not using > exchange. For troubleshooting log, Tools -> Options -> Other. The log is a bit difficult to read because of all the garbage that Microsoft left in it. Look for the lines that have "SMTP" in them to show what commands Outlook sent to the SMTP server. You need to enable the troubleshooting log, exit Outlook, and then restart Outlook for the logging to start. "i can see wether the mail is getting to the smtp server as i can acess it on the web". What was that supposed to mean? That you send yourself test e-mails and you can see that they arrive in whatever e-mail account you sent them to? Was this after the long delay you said happens when sending and using Outlook? One minute is way too short a polling interval. You might not get done finishing the first mail poll before you start to execute the next one while you already have your mailbox in use for the first mail poll. Up it to 5 minutes. It is unlikely that you really get e-mails so fast an furious that you get super critical ones that you need instantly and that you could possible take action on them all within 1 minute. Do you have the option enabled to Send Immediately? If not, your outbound mail will wait to get sent on the next scheduled mail poll. Signature_________________________________________________________________ Post your replies to the newsgroup. Share with others. E-mail: vanguard_help AT yahoo.com (append "#NEWS#" to Subject) _________________________________________________________________ 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 >> how do i enable the troubleshooting log, i can see wether the mail is >> getting to the smtp server as i can acess it on the web, it is not, mail [quoted text clipped - 22 lines] > Do you have the option enabled to Send Immediately? If not, your outbound > mail will wait to get sent on the next scheduled mail poll. > 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. Signature_________________________________________________________________ Post your replies to the newsgroup. Share with others. E-mail: vanguard_help AT yahoo.com (append "#NEWS#" to Subject) _________________________________________________________________ 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.... >> 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. 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 [quoted text clipped - 8 lines] >> Outlook's troubleshooting logfile is in %temp%\opmlog.txt; see >> http://support.microsoft.com/?id=300479. 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: [quoted text clipped - 21 lines] >>> Outlook's troubleshooting logfile is in %temp%\opmlog.txt; see >>> http://support.microsoft.com/?id=300479. > found the opm log but no mention of smtp just tx and rx... what do i > do now? [quoted text clipped - 24 lines] >>>> 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. Signature_________________________________________________________________ Post your replies to the newsgroup. Share with others. E-mail: vanguard_help AT yahoo.com (append "#NEWS#" to Subject) _________________________________________________________________ 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? [quoted text clipped - 102 lines] > logging, exit Outlook, delete the old logfile, start Outlook, send a test > e-mail, exit Outlook, and post the logfile. http://www.webuser.co.uk/cgi-bin/forums/showflat.pl?Cat=&Board=email&Number=1263 73&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 [quoted text clipped - 110 lines] >> logging, exit Outlook, delete the old logfile, start Outlook, send a test >> e-mail, exit Outlook, and post the logfile. > 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? SignatureJeff Stephenson Outlook Development This posting is provided "AS IS" with no warranties, and confers no rights > 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). Signature_____________________________________________________________ Post your replies to the newsgroup. Share with others. For e-mail: Remove "NIXTHIS" and append "#VS811" to Subject. _____________________________________________________________ > 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 [quoted text clipped - 12 lines] > 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...). SignatureJeff Stephenson Outlook Development This posting is provided "AS IS" with no warranties, and confers no rights 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 >> Could you turn on logging as Vanguard suggested, then send a message and >> post the log? [quoted text clipped - 15 lines] > an error in getting the message to the mail server so there are continual > retries). > 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. SignatureBrian Tillman 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 >> 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. > 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. SignatureJeff Stephenson Outlook Development This posting is provided "AS IS" with no warranties, and confers no rights 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. > tried that and they sent the following, > [quoted text clipped - 34 lines] >> 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. Dear Peter, Thank you for your email. Wanadoo email accounts that look like this mail@username.wanadoo.co.uk 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 > http://www.webuser.co.uk/cgi-bin/forums/showthreaded.pl?Cat=&Board=email&Number= 153244 > [quoted text clipped - 55 lines] >>> 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. Sounds possible.....but why doesn't outlook put an id in and why does fs take so long to invent its own > Dear Peter, > [quoted text clipped - 78 lines] >>>> 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. > 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. SignatureJeff Stephenson Outlook Development This posting is provided "AS IS" with no warranties, and confers no rights > http://www.webuser.co.uk/cgi-bin/forums/showthreaded.pl?Cat=&Board=email&Number= 153244 > [quoted text clipped - 57 lines] >>> an Outlook problem and you;ll have to contact the admins of the >>> server. 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. Signature_____________________________________________________________ Post your replies to the newsgroup. Share with others. For e-mail: Remove "NIXTHIS" and append "#VS811" to Subject. _____________________________________________________________ is there any solution to this or simply go back to outlook 2002 >> http://www.webuser.co.uk/cgi-bin/forums/showthreaded.pl?Cat=&Board=email&Number= 153244 >> [quoted text clipped - 81 lines] > not rejected by spam filters. Could even be the receiving SMTP servers > use greylisting to ensure that what spews from Wanadoo isn't spam. a typical case of both parties saying, its nothing to do with us guv.... > is there any solution to this or simply go back to outlook 2002 > [quoted text clipped - 84 lines] >> receiving SMTP servers use greylisting to ensure that what spews from >> Wanadoo isn't spam. > 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. 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 >> is there any solution to this or simply go back to outlook 2002 > [quoted text clipped - 14 lines] > 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. > 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. > [quoted text clipped - 3 lines] > 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 <1234@bar.com> 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... SignatureJeff Stephenson Outlook Development This posting is provided "AS IS" with no warranties, and confers no rights > So if I want to spoof, I just use a Message-Id of <1234@bar.com> 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: <zni3hzloe1cn.dlg@jeff.stephenson.microsoft.com>" 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. >... > [quoted text clipped - 8 lines] > 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 f.cked 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). >... > [quoted text clipped - 8 lines] > 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 f.cked 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). > ... > You are correct to identify the message ID as a source of the [quoted text clipped - 6 lines] > emails are then manually checked for their validity before being > forwarded to the recipient. (Sent this twice before. Didn't appear on msnews.microsoft.com, or it showed as "no longer on server" although just posted today. Maybe the third time is charmed, and will try a different NNTP server. So forgive if you see my post 3 times. Microsoft's server accepted my posts but won't show them [to me], and I didn't see a FollowUp-To header that would hide my reply into some other group.) 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 f.cked 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). Signature____________________________________________________________ Post your replies to the newsgroup. Share with others. E-mail reply: Remove "NIXTHIS" and add "#VS811" to Subject. ____________________________________________________________ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.