|
| If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|||||||
|
|
Thread Tools | Display Modes |
|
#2
June 4th, 2004, 10:52 AM
|
|||
|
|||
Frequent Non-Delivery,MSOE to Lycos: Persistent Transient Failure
In article , says...
I'm using MSOE 6.0 (6.00.2800.1123) with IE 6.0 (6.0.2.800.1106.xpsp2.030422-1633). I'm running the Home Edition of XP, with SP2. I connect via a modem dial up, usually at 53.2 Kbps. My ISP is AT&T Worldnet. I'm not on a local network; my machine stands alone, and I'm the sole user of my system. Formatted messages which I send to the Lycos on-line E-mail address of a non-computer-literate correspondent are often returned to me under cover of Plain Text messages. The messages are being sent to me by my own mail server ( ), which is named in the "From" field of the message caption as "Postmaster." All of the cover messages follow this form: +++++++++++++++++++++ A message (from My Address ) was received at 25 May 2004 6:52:44 +0000. The following addresses had delivery problems: (The Address to which I wrote) Persistent Transient Failu Delivery time expired Delivery last attempted at 25 May 2004 6:53:22 +0000 +++++++++++++++++++++ snipped major verbal description of delivery failure notice This is the content of one of *'dat files which I opened in WordPad: +++++++++++++++++++++ Reporting-MTA: dns; worldnet.att.net Arrival-Date: 30 May 2004 16:02:22 +0000 Final-Recipient: rfc822; (Address to which I wrote) Action: failed Status: 4.4.7 Unable to contact host for 1 days, Diagnostic-Code: smtp; Persistent Transient Failu Delivery time expired Last-Attempt-Date: 30 May 2004 16:02:25 +0000 +++++++++++++++++++++ The Subject line of these messages is always "Returned mail: delivery problems encountered." I don't think it's relevant, but I've noticed from the times of day which are mentioned in those skimpy error texts that the system clock of the system to which I'm writing (in the same time zone) is about four hours fast. Last point first; are you sure that there isn't a UTC offset? Your examples include a UTC offset of +0000, meaning that the time shown should be taken as 4:00 P.M., Universal Coordinated Time (UTC), which was formerly known as Greenwich Mean Time (GMT). Well, there are some slight technical differences, for those who know. Aside from that, what you are seeing is a standard delivery failure notice, or "bounce". The AT&T Worldnet MTA was unable to deliver the email to the designated Lycos Web Mail MX after some period of time, or that server is just rejecting email from the AT&T Worldnet MTA. So the message was returned to you with a description of the reason for the failure. My experience is that the MTA delivering the bounce may not provide an accurate transcript of the cause of the failure. One thing is absolutely certain: MSOE is not the reason that your email is bouncing. Unless you have a typo in the destination email address; but I would expect an error related to the 5xx code the destination MX would return. The rest of it, the way that MSOE presents the email, is a feature of the way that MSOE is handling the MIME type of the bounce. There may be something that you can do about that, but I can't say for sure; I don't use MSOE, except on rare occasions. -- Norman ~Win dain a lotica, En vai tu ri, Si lo ta ~Fin dein a loluca, En dragu a sei lain ~Vi fa-ru les shutai am, En riga-lint 
|
|
#3
June 4th, 2004, 04:04 PM
|
|||
|
|||
|
Non-Delivery,MSOE to Lycos: Persistent Transient Failure
Norman: Your reply is ** excellent **. Thanks very much. I'll respond to each of your points. I'll set your comments off by "dividers" and by item numbers. I'll begin by replying to your final comments first. I'll use an item number which is consistent with their position at the end of your message. They pretty much summarize this discussion. Then, for you and for anyone else who may be interested, as well as for the Google Groups archive and for readers in the future, I'll provide extensive details below, in response to your other, much-appreciated comments. I found no citations of "Persistent Transient Failure" when I searched Google Groups, so this detail may help to fill that gap: +++++++++++++++++++++ 3. One thing is absolutely certain: MSOE is not the reason that your email is bouncing. Unless you have a typo in the destination email address; but I would expect an error related to the 5xx code the destination MX would return. The rest of it, the way that MSOE presents the email, is a feature of the way that MSOE is handling the MIME type of the bounce. There may be something that you can do about that, but I can't say for sure; I don't use MSOE, except on rare occasions. +++++++++++++++++++++ Yes, I doubted this was occuring "at my end," based on my past good experience with MSOE. AT&T Worldnet's a new ISP for me, of only six month's experience, but it also seems to be "OK." I'm writing to someone who's "as rich as Croesus," but who seems to be relying on a free Lycos web-based E-mail account. Perhaps "you get what you pay for," and perhaps the free Lycos web-based E-mail is more likely to create such problems. Before I troubled this group, I searched Google Groups for any mention of this problem (I found none), and I also checked the Lycos mail pages, and their Help database. That gave me a view of the service, and my impression was that it isn't exactly aimed at "savvy" personal computer users. As discussed below, in item 1B, there doesn't seem to be any chance of a "typo" in the address to which I'm writing. Thanks for confirming that Outlook Express isn't doing this. I'll assume this is the type of problem one can expect to see when one is using free web-based E-mail. Optional details are provided below: +++++++++++++++++++++ 1. Last point first; are you sure that there isn't a UTC offset? Your examples include a UTC offset of +0000, meaning that the time shown should be taken as 4:00 P.M., Universal Coordinated Time (UTC), which was formerly known as Greenwich Mean Time (GMT). Well, there are some slight technical differences, for those who know. +++++++++++++++++++++ A couple of points here. A. I'd expect such a time factor (the "UTC Offset") to affect * all * messages which were exchanged between the two addresses. [Let me just say here, for the benefit of anyone who might wish to download this software, that I use the NIST's very nice, free, on-line NIST System Clock Synchronization Utility, NISTIME 32, aka TCP/IP Daytime Client. It adjusts my system clock to the NIST's atomic clock in Boulder, Colorado, via any of a number of servers. It's available at http://www.boulder.nist.gov/timefreq/service/its.htm I highly recommend it. I check and correct my ssytem clock at least once a day, and it's rarely inaccurate by more than a few fractions of a second.] I only experience these E-mail delivery problems when I'm writing to one correspondent. I'm no "power user," by any means, but I can say that this person has so little inclination to discuss personal computing technology that I don't even know how limited his skills are. Evidence suggests he's barely getting by with almost no skills at all. It's reasonable to assume his system clock is grossly inaccurate. I studied the times of day which were associated with six mail returns from 4-8-04 through 6-2-04, and all of them independently suggested his clock was approximately four hours fast. B. I've been writing to this "problem" address since 2-1-04. Between that date and the first return of mail, on 4-8-04, I sent 16 messages, none of which was returned to me, and I received 7 messages from the other person. In all that time, and since, I've been writing to the same address which I've stored in the Shared Contacts folder of my Outlook Express Address Book. (I'm the sole user of my stand-alone system, and all my MSOE addresses are in the Shared Contacts folder; none is in the folder for my name, which is the only "named identity" in MSOE on my system.) I don't think any change or error in the syntax of the address is involved in this problem. C. The first returned message was received on 4-8-04, and it was the first of six which have come to me since then. They all have the same format, although the details of the failed messages, and the dates and times of day are all different, of course. In that same interval of time, from the date of the first returned message to the present, 24 messages which I sent weren't returned, and were assumed to have been received, and I received 5 replies from the other person. I think this information shows that the "returned mail"/"Transient Persisten Failure" problem is intermittent. It doesn't affect all the messages which I send, and it doesn't even affect most of them. +++++++++++++++++++++ 2. Aside from that, what you are seeing is a standard delivery failure notice, or "bounce". The AT&T Worldnet MTA was unable to deliver the email to the designated Lycos Web Mail MX after some period of time, or that server is just rejecting email from the AT&T Worldnet MTA. So the message was returned to you with a description of the reason for the failure. My experience is that the MTA delivering the bounce may not provide an accurate transcript of the cause of the failure. +++++++++++++++++++++ D. Thanks for those general comments. You mention "after some period of time," and your competence is obvious, but I want to stress that the "period of time" seems to be minimal. Here's the full message body of the "cover message" from my mail server, which reported the first return of mail: ============== A message (from MyAddressRemoved) was received at 3 Apr 2004 20:17:38 +0000. The following addresses had delivery problems: (TheOtherPerson'sAddressRemoved) Persistent Transient Failu Delivery time expired Delivery last attempted at 3 Apr 2004 20:17:39 +0000 ============== I'll assume I'm correct about the apparent "four hours fast" system-clock discrepancy between my system and the one to which I'm writing. (The other system seems to be "four hours fast.") I sent that first returned message on Saturday, April 03, 2004, at 4:17 PM. Translating that to the "24-hour-clock" format gives "16:17:XX." (I don't have the seconds value of the time of day on my copy of the sent message.) Adding the four hours for the presumed discrepancy of the respective system clocks gives a "sent" time of "20:17:XX." You can see that my server is telling me my message was "received" (it doesn't say whether it's referring to its receipt of my message, or to the receipt of my message by the Lycos mail server of the person to whom I was writing) at "20:17:38 +0000," on the same date. This very skimpy explanatory text then states the last attempt at delivery was made on the same day, at "20:17:39 +0000," which is ONE SECOND later! That's hardly a "persistent" failure! Like everyone else, I've occasionally had mail returned to me over the years. However, it's usually returned with a very detailed explanation, which thoroughly explains what happened. The message body which I showed you above can't begin to compare with what I always received in the past, from other ISPs. I'll show you the entire contents of the *.dat file which was sent as an attachment of that "cover message" from my mail server, together with a returned, formatted copy of my original message (which hadn't been delivered). My purpose in showing you that is to show that it doesn't provide much more detail. Perhaps I should first explain that I save all my E-mail "outside" MSOE, in my "data hierarchy," which was once "My Documents." I use full file paths as headers on each page of my "workaday" files, of which I have tens of thousands. (I then use those full headers in the texts of files when I refer to other files. That facilitates navigation in my large data hierarchy. I re-named "My Documents" by using a single hyphen, i.e. " - ", to save space in those headers. This particular message, # 249, is saved in a "correspondence" folder as C:\-\Ppl\Knwn\Files\(Person'sNameRemoved)\Crrs\2004\24 9 I'm mentioning that because filing the E-mail messages as "stand alone" *.EML files "outside" MSOE's own folders might affect the changes which I reported in the file-names of these "ATT...dat" files. In this case, when I first opened the message to which this file is attached this morning (without opening this file itself; merely viewing it as an attachment in the "Attach" field of the header of the message) it was listed in the message's "Attach" field as "ATT00026.dat (235 bytes)." I then closed and re-opened the message to which that file was attached, and, each time the message was re-opened, the numerical portion of the file name "advanced" to a higher value. Successively, it moved up from ...26... to 38, 50, 62, 74, 86, etc.! OK; "no more suspense"; here's all of its skimpy content: ============== Reporting-MTA: dns; worldnet.att.net Arrival-Date: 3 Apr 2004 20:17:38 +0000 Final-Recipient: rfc822; (Address To Which I Wrote Removed) Action: failed Status: 4.4.7 Unable to contact host for 1 days, Diagnostic-Code: smtp; Persistent Transient Failu Delivery time expired Last-Attempt-Date: 3 Apr 2004 20:17:39 +0000 ============== You can see that it's almost the same information which was provided in the message body of the message to which it was attached. The comment about "Unable to contact host for 1 days" seems preposterous, inasmuch as my above explanation suggests one server or the other didn't spend more than * one second * in the alleged "attempts" to deliver the mail, let alone an entire day of "persistent" efforts... It seems to be worth repeating: "You get what you pay for..." -- Jeff Hook NJ, USA
|
|
#4
June 4th, 2004, 05:40 PM
|
|||
|
|||
|
Non-Delivery,MSOE to Lycos: Persistent Transient Failure
In article , Jeffrey L. Hook says...
Your reply is ** excellent **. Thanks very much. I'll respond to each of your points. I'll set your comments off by "dividers" and by item numbers. I'll begin by replying to your final comments first. I'll use an item number which is consistent with their position at the end of your message. They pretty much summarize this discussion. Then, for you and for anyone else who may be interested, as well as for the Google Groups archive and for readers in the future, I'll provide extensive details below, in response to your other, much-appreciated comments. I found no citations of "Persistent Transient Failure" when I searched Google Groups, so this detail may help to fill that gap... Look up RFC 2821 and RFC 2822. Together they describe how SMTP is supposed to work, and may be of some help to you. I have tried to edit, and reply "in-line" in a fashion that won't detract from your post, but touch on the highlights. +++++++++++++++++++++ 1. Last point first; are you sure that there isn't a UTC offset? Your examples include a UTC offset of +0000, meaning that the time shown should be taken as 4:00 P.M., Universal Coordinated Time (UTC), which was formerly known as Greenwich Mean Time (GMT). Well, there are some slight technical differences, for those who know. +++++++++++++++++++++ A couple of points here. A. I'd expect such a time factor (the "UTC Offset") to affect * all * messages which were exchanged between the two addresses. [Let me just say here, for the benefit of anyone who might wish to download this software, that I use the NIST's very nice, free, on-line NIST System Clock Synchronization Utility, NISTIME 32, aka TCP/IP Daytime Client. It adjusts my system clock to the NIST's atomic clock in Boulder, Colorado, via any of a number of servers. It's available at http://www.boulder.nist.gov/timefreq/service/its.htm Yes; I use it myself. Alas, I found that a BitTorrent download can play havoc with the system clock, and probably need to set a periodic query for half hour increments during a download. Currently I only make the query at system boot. I only experience these E-mail delivery problems when I'm writing to one correspondent...It's reasonable to assume his system clock is grossly inaccurate. I studied the times of day which were associated with six mail returns from 4-8-04 through 6-2-04, and all of them independently suggested his clock was approximately four hours fast. But I wouldn't think that your correspondent's system clock should affect the SMTP process in any way. I've seen a correspondent with a system clock off by a year, and his email was processed normally from end to end. I don't think any change or error in the syntax of the address is involved in this problem. Based on the information that you have provided, I would have to agree. I just tossed it out as a possibility to check. I think this information shows that the "returned mail"/"Transient Persisten Failure" problem is intermittent. It doesn't affect all the messages which I send, and it doesn't even affect most of them... ...Thanks for those general comments. You mention "after some period of time," and your competence is obvious, but I want to stress that the "period of time" seems to be minimal. Here's the full message body of the "cover message" from my mail server, which reported the first return of mail: ============== A message (from MyAddressRemoved) was received at 3 Apr 2004 20:17:38 +0000. The following addresses had delivery problems: (TheOtherPerson'sAddressRemoved) Persistent Transient Failu Delivery time expired Delivery last attempted at 3 Apr 2004 20:17:39 +0000 ============== I'll assume I'm correct about the apparent "four hours fast" system-clock discrepancy between my system and the one to which I'm writing. (The other system seems to be "four hours fast.") I sent that first returned message on Saturday, April 03, 2004, at 4:17 PM. Translating that to the "24-hour-clock" format gives "16:17:XX." (I don't have the seconds value of the time of day on my copy of the sent message.) Adding the four hours for the presumed discrepancy of the respective system clocks gives a "sent" time of "20:17:XX." You can see that my server is telling me my message was "received" (it doesn't say whether it's referring to its receipt of my message, or to the receipt of my message by the Lycos mail server of the person to whom I was writing) at "20:17:38 +0000," on the same date. This very skimpy explanatory text then states the last attempt at delivery was made on the same day, at "20:17:39 +0000," which is ONE SECOND later! That's hardly a "persistent" failure! I believe that you will find one of the RFCs that I cited will cover SMTP return codes. 4xx is supposed to indicate a temporary failure, 5xx a permanent failure. Retries are permissible on 4xx errors, but a 5xx error should cause an MTA to give up. But there are also time periods to be considered for the retries. I've seen MTAs which will queue retries for up to six days; but the RFCs may allow for shorter retry periods. I haven't studied them thoroughly. Yet. Also, your MTA will not record the time of successful delivery to the Lycos MTA. If the message is delivered, you will get no status indication at all; unless return receipt requests are honored. The only time status you should get from an MTA is that about the message which failed; and only referring to the system time of the reporting MTA. But this actually appears to be a problem with the AT&T MTA. I mentioned BitTorrent earlier; it is a distributed file sharing program which can load system resources mercilessly. Along with upsetting my system clock, it also upset my MTA. I run the MTA as a sort of hobby, for personal email only. I watched the Sneakemail MTA try to deliver email to my MTA during a BitTorrent download, and the transaction always timed out after an excess of 150 seconds, or so. The Sneakemail MTA kept retrying until the download was complete and my computer became more responsive. It looks to me as if the AT&T MTA is giving up way too soon. Again, any system clock errors should not have an impact on SMTP delivery. Like everyone else, I've occasionally had mail returned to me over the years. However, it's usually returned with a very detailed explanation, which thoroughly explains what happened. The message body which I showed you above can't begin to compare with what I always received in the past, from other ISPs. I'll show you the entire contents of the *.dat file which was sent as an attachment of that "cover message" from my mail server, together with a returned, formatted copy of my original message (which hadn't been delivered). My purpose in showing you that is to show that it doesn't provide much more detail. I have experienced returns which bear little resemblance to the failure code which triggered the return. I can't find an example, right now, but someplace I am sure I have a return when I was testing a non-existent address at my domain. My MTA refuses email with a non-existent local part. The sending MTA will generate a return to the envelope sender of the email. It should include my MTA's return code, "550 Address not known"; but, for some reason known only to the mail system administrator, that MTA returned a failure message completely unrelated to my MTA's return code. It seems to be worth repeating: "You get what you pay for..." Maybe, maybe not. Lycos Web Mail is free, to be sure, but they don't seem to be the source of the problem so much as your paid AT&T Worldnet Service; which appears to be giving up on temporary delivery failures too soon. -- Norman ~Win dain a lotica, En vai tu ri, Si lo ta ~Fin dein a loluca, En dragu a sei lain ~Vi fa-ru les shutai am, En riga-lint
|
|
#5
June 5th, 2004, 04:24 AM
|
|||
|
|||
|
Non-Delivery,MSOE to Lycos: Persistent Transient Failure
Norman: Wow! You've gone WAY over my head in your second detailed response. Let me try once again to summarize what I * think * you're saying, and then I'll try to provide some clarification of the arcane points of information which you mentioned, for the education of any other readers of this thread. It seems I was * completely wrong * in my assessment of this E-mail-delivery problem. I thought you were suggesting that Lycos' Web Mail was responsible for the inability of some of my messages to reach the Lycos E-mail account of my correspondent. I'd provided the information which showed my own AT&T Worldnet mail server was spending no more than about one second in its "attempts" to deliver my mail, so I should've been smart enough to interpret that information myself, and to suspect that my own server was causing this problem. It seems the AT&T Worldnet server's "giving up" much too soon. I don't know what I can do about that. Maybe I can write to my ISP. I suppose I can't change the behavior of my own ISP's mail server, such as by changing settings. I assume I don't have any direct access to whatever's wrong. At any rate, you brought in several topics of which I'd had no prior awareness, so let me now try to clarify those for other inexpert readers of this thread, who might wish to benefit from your contributions. However, I warn readers that this isn't "light" material! If you'd like to follow Norman Miller into the "Heart of the Internet," read on: +++++++++++++++++++++ Look up RFC 2821 and RFC 2822. Together they describe how SMTP is supposed to work, and may be of some help to you. +++++++++++++++++++++ I had no idea at all what "RFCs" were, but I found a good explanation of them in FOLDOC, at http://www.nightflight.com/foldoc/fo...t+For+Comments +++++++++++++++++++++ Request For Comments (RFC) One of a series, begun in 1969, of numbered Internet informational documents and standards widely followed by commercial software and freeware in the Internet and Unix communities. Few RFCs are standards but all Internet standards are recorded in RFCs. Perhaps the single most influential RFC has been RFC 822, the Internet electronic mail format standard. The RFCs are unusual in that they are floated by technical experts acting on their own initiative and reviewed by the Internet at large, rather than formally promulgated through an institution such as ANSI. For this reason, they remain known as RFCs even once adopted as standards... +++++++++++++++++++++ You mentioned two prominent RFCs. I learned all of the documents are available at http://www.rfc.net/ That page also offers a concise explanation of RFCs: +++++++++++++++++++++ What is an RFC? An RFC is a document describing the standards that make the Internet work. An RFC starts life as an Internet Draft. The Internet Draft is proposed to the IETF, whereupon voting and modification occurs until it either becomes obsolete due to lack of interest or is accepted by the IESG, whereupon it is assigned an RFC number and published as an RFC. The process by which an RFC is produced is described in detail in RFC 2026. Further information on the RFC documents and the IETF, the body that produces them, can be had at http://www.rfc-editor.org, the home of the RFC Editor. While the RFC Editor was once a single individual, the legendary Jon Postel, it is now a group funded by the Internet Society... +++++++++++++++++++++ RFC 2821 (SMTP) is at http://rfc.net/rfc2821.html and RFC 2822 (SMTP email headers) is at http://rfc.net/rfc2822.html Oh yes: RFC 2821 is ** 79 ** standard-sized word-processing-document pages long, and RFC 2822 is ** 51 ** such pages in length. In commenting about using such on-line system-clock "synchronizers" as I identified, you said +++++++++++++++++++++ I found that a BitTorrent download can play havoc with the system clock, and probably need to set a periodic query for half hour increments during a download. +++++++++++++++++++++ I suspect I'm not the only reader of this thread who had no idea what a BitTorrent is. I found a well-illustrated, acceptable explanation at http://www.techweb.com/encyclopedia/...rent&x=36&y=11 That topic hardly seems essential to a discussion of the mail-delivery problem which was the basis of this thread, so I think an investigation of "BitTorrent" is optional. You said: +++++++++++++++++++++ But I wouldn't think that your correspondent's system clock should affect the SMTP process in any way. I've seen a correspondent with a system clock off by a year, and his email was processed normally from end to end. +++++++++++++++++++++ Yes. I was only using the reported times of day which were provided in the cover messages from my mail server to suggest how much time was spent by my server (or my correspondent's server) in attempting to deliver the mail, before a failure was declared. I appreciated your explanation that the "UTC offset of +0000" suggested my correspondent hadn't even set his system clock to the correct time zone. It seems he's running UTC/GMT, although he and I are both in the same state, in the eastern time zone of the USA. We're now four hours behind UTC/GMT, because our "Daylight Savings Time" subtracts one hour from the usual five-hour "lead" of London time. You continued: +++++++++++++++++++++ I believe that you will find one of the RFCs that I cited will cover SMTP return codes. 4xx is supposed to indicate a temporary failure, 5xx a permanent failure. Retries are permissible on 4xx errors, but a 5xx error should cause an MTA to give up. But there are also time periods to be considered for the retries. I've seen MTAs which will queue retries for up to six days; but the RFCs may allow for shorter retry periods. I haven't studied them thoroughly. Yet. Also, your MTA will not record the time of successful delivery to the Lycos MTA. If the message is delivered, you will get no status indication at all; unless return receipt requests are honored. The only time status you should get from an MTA is that about the message which failed; and only referring to the system time of the reporting MTA. But this actually appears to be a problem with the AT&T MTA. I mentioned BitTorrent earlier; it is a distributed file sharing program which can load system resources mercilessly. Along with upsetting my system clock, it also upset my MTA. I run the MTA as a sort of hobby, for personal email only. I watched the Sneakemail MTA try to deliver email to my MTA during a BitTorrent download, and the transaction always timed out after an excess of 150 seconds, or so. The Sneakemail MTA kept retrying until the download was complete and my computer became more responsive. It looks to me as if the AT&T MTA is giving up way too soon. Again, any system clock errors should not have an impact on SMTP delivery. +++++++++++++++++++++ I was unfamiliar with the acronym "MTA." For other "ignorami," I provide this clarification, also from FOLDOC, at http://www.nightflight.com/foldoc/fo...Transfer+Agent +++++++++++++++++++++ Message Transfer Agent (MTA, Mail Transport Agent) The program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another MTA it stores it temporarily locally and analyses the recipients and either delivers it (local addressee) or forwards it to another MTA (routing). In either case it may edit and/or add to the message headers. The most widely used MTA for Unix is sendmail, which communicates using SMTP. +++++++++++++++++++++ I emphatically agree with you that true "persistence" always seemed to be shown by MTAs in past "non-delivery" incidents which I'd seen until now. I'd also always seen reports from servers that they'd attempted to deliver mail over the course of several * days * before they'd "given up" and declared failure. That contrasts markedly with the apparent "one-second" "effort" of my MTA. You said: +++++++++++++++++++++ I have experienced returns which bear little resemblance to the failure code which triggered the return. I can't find an example, right now, but someplace I am sure I have a return when I was testing a non-existent address at my domain. My MTA refuses email with a non-existent local part. The sending MTA will generate a return to the envelope sender of the email. It should include my MTA's return code, "550 Address not known"; but, for some reason known only to the mail system administrator, that MTA returned a failure message completely unrelated to my MTA's return code. It seems to be worth repeating: "You get what you pay for..." Maybe, maybe not. Lycos Web Mail is free, to be sure, but they don't seem to be the source of the problem so much as your paid AT&T Worldnet Service; which appears to be giving up on temporary delivery failures too soon. +++++++++++++++++++++ Yes. Not only did my AT&T Worldnet server send me much skimpier reports than I'd ever received from other "MTAs" in the past, about non-delivery problems, but I sensed the reports might not have been very accurate. I guess I'll try to absorb this new, detailed information which you've pointed out to me. For example, I'll try at least to find the most relevant portions of the RFCs which you recommended. Then it looks like I'd better communicate with someone at AT&T Worldnet, my own ISP. Oh, while I'm at it... my curiosity's "killing" me. Can you at least identify the languare of your signature script, if you don't wish to provide an English translation? ~Win dain a lotica, En vai tu ri, Si lo ta ~Fin dein a loluca, En dragu a sei lain ~Vi fa-ru les shutai am, En riga-lint I entered that text at http://odur.let.rug.nl/~vannoord/TextCat/Demo/ and, as I suspected, I was told it was in Romanian. I attempted to obtain a free "demo" machine translation, at the English-language pages of http://www.catalinzaharia.go.ro/e_index.html but it seemed the site wasn't in operation when I made my attempt. Do I at least have the correct language? -- Jeff Hook NJ, USA
|
|
#6
June 8th, 2004, 12:59 AM
|
|||
|
|||
|
Non-Delivery,MSOE to Lycos: Persistent Transient Failure
To All: While I'm waiting to hear from Norman Miller about the foreign-language text which appears in his signature, I thought I'd add this PS to my own thread. Norman suggested the problem of my returned mail wasn't with Microsoft Outlook Express, or with the Lycos Web Mail of the person to whom I was writing. Instead, Norman believed the problem was with my own AT&T Worldnet mail server ("MTA"). I had provided text from my own server's "returned mail cover messages," and from attached ATT *.dat files, which both suggested my own mail server had claimed "Permanent Transient Failures" precluded delivery of messages, even though it seemed the server hadn't sustained its attempts at delivery for more than a second or two. I went to AT&T Worldnet's Help web pages, and I found they support a newsgroup about problems with their mail servers, at worldnet.help.service-issues.mail-server I've only begun to read that group, but as Norman would probably expect, I see many message headers about "returned mail." I offer these remarks to suggest to other users how they might investigate similar problems of mail being returned as "undeliverable" when their own mail servers report only brief attempts at delivery. It looks like the inconsistency between claims of "permanent transient failures" and minimally-sustained delivery attempts suggests malfunctions by the "sending" server, rather than by the "receiving" server. -- Jeff Hook NJ, USA
|
| Thread Tools | |
| Display Modes | |
|
|
Linear Mode
