As of 06.30 am today 1 Jun 2007, test e-mails arrived at their destinations promptly. It seems the ISP is getting it's act together. Their website claims that test transmissions to all major ISP are now OK, with the exception of AOL.

It is disappointing that this turned out to be a non-event, in the sense that there was no technical problem to chase down and resolve. It was pleasing to find that Pegasus Mail was blameless.

Finally, it was nice to discover this forum, and come away with the comforting feeling that any future problems are no longer likely to be major obstacles.

Thanks, everybody.

Yesterday (24 May), and suddenly, all outgoing messages failed to arrive at their respective destinations. This applied to all messages to all confirmable destinations from Pegasus under various identities, all messages from the SeaMonkey (Mozilla) browser mail client, and also from the website mail client of my broadband provider.

It is as if some power had decreed "Henceforth, thou shalt not communicate with the outside world". The tap was suddenly turned off.

 There are no postmaster messages about delivery failure. The operations to compose message and send messages all appear to execute as normally as ever - all is normal, but the mail never gets to the target.

Incoming mail continues to work as perfectly as ever, as does the wonderful Pegasus Mail which I have happily used since migrating from DOS to Windows in the early 1990's.

As far as I can tell, nothing on my system changed between normal and abnormal behaviour. 

My system is a single user standalone machine, with Windows XP Pro and a broadband service.

The Sygate Personal Firewall is innocent, and the Windows firewall appears to be likewise blameless but it is too unfriendly and time consuming to be sure that I have not missed something (and why would it change ?).

Any ideas, suggestions, explanations, prayers, and magical spells all welcome.

Incidentally, the NAV Dropper thread was very impressive for the cooperative effort by all the contributors. Great stuff.

Usually when outgoing messages fail to arrive, I start looking at the configuration.

You haven't told us much about your setup:-

Do you use a relay host and how do you authenticate?

Have you got an internet log from your failed transfer?

Paul, thanks for your interest in the problem.

> Usually when outgoing messages fail to arrive, I start looking at the configuration.

Me too - first thing I did. All as should be. In fact I have not found anything different in any aspect that I can think of. I am an experienced systems analyst and programmer, so you can talk dirty to me, but telecommunications have always been a happy user experience rather than an area I have ever needed to get to grips with.

 > Do you use a relay host and how do you authenticate?

I am not familiar with the usage of the terms in the question. The SMTP server address of my ISP has 'mail.xxxxxxx.co.uk' format, where the x's represent the ISP name. Presumably this might be a relay, but I would guess the server is located at the ISP.

If by authenticate you mean the username / password pair, the dial up section in the Connections tab in Internet Options (Control panel) specifies those, and they are as they should be. If these were wrong, I would have expected some sort of response from the postmaster at the ISP rejecting the transmissions.

The total absence of any error or objection messages from any quarter is one very puzzling aspect of this incident. In fact, if I had not decided to send a test message to one of my other PMail identities, I would not have known about delivery failure until much later. Everything looks and behaves normally.

> Have you got an internet log from your failed transfer?

 Don't know. If something somewhere in the XP system keeps a log, I would be interested in knowing how to access it.

The Sygate firewall logs just record the result of permissions and filters either as a pass or a block. So the log shows PMail being allowed to send outgoing transmissions whenever I have sent mail, but nothing is known about what happens to them thereafter.

I am not quite sure where Sygate sits in the chain of events after I click the PMail send button. However, thinking about that has sparked a train of thought and memories. There at least two other common ingredients with SMTP transmissions from PMail. One is Windows sockets, and the other is the DSL. If the DSL was having a problem I would have expected some sort of error message or maybe a failure of incoming mail (which has not happened).

However, Microsoft's sockets are something else. I would not be surprised by anything from them, including total silence about a change of behaviour. And that reminds me of two other things which may or may not be related to the problem.

First, I have found that I can get e-mail delivered to anybody I want by using a web-mail account with another ISP. The account is not directly accessible to Pegasus, and I have to browse to the web site and use their mail client. But it works - presumably because when I click the send button there, their software and server are working independently of both my machine and my broadband ISP's server.

This narrows the list of suspects - and we come back to Winsock. I was trying to help a friend set up his copy of PMail to send mail. It had been sending mail, but had stopped when he replaced his 56Kb modem with broadband. The change did not affect his incoming mail. So, eventually, I got to browsing through the PMail Prefernces and Settings options. I came to the Advanced section in the General settings, and one of the choices there is to set how  WSOCK32.dll is loaded. The default is On Demand Only, and I had never touched that setting ever since it had become available in PMail.

The other choices are Never, and Always. I could understand the reasons and logic for these choices. As I now had a fast machine, and oodles of memory I figured that loading the .dll Always would not be a problem, and set that choice. I finished my browsing, closed Pegasus and telephoned my friend with some suggestions for his problem.

To my surprise,  when I fired up PMail later, a message immediately appeared "Extension disabled...". Before I could read and digest the remainder, the message was replaced by the main Pegasus window. I guessed that the settings change for WSOCK32.dll loading was responsible and set it back to On Demand Only. No more message. I was drafting a long e-mail, and did some more work on that and closed Pegasus.

E-mail is very important to my current life, and when I returned to my machine later, some instinct prompted me to test the system by sending an e-mail to one of my other PMail identities. Nothing arrived. Many hours later, after much failed testing, and scouring the net for help, I came upon this forum, read the NAV Dropper saga, and joined immediately.

   ---oOo---

I apologise to Paul and any other Kind Readers for the length of this narrative. Paul's questions sparked a train of thought and memories, and I felt that maybe David Harris or one of his colleagues might be able to throw some light on the WSOCK32.dll episode. (And maybe its relevance, if any, to the vanishing mail problem.)

If there is anything else you want to know about my setup, Paul, everything is available.

The first thing you need to do is determine if the mail is getting to the SMTP host.  Go to File | Network configuration | General and turn on "Create Internet session logs (advanced diagnostic use only)" 

Checking this control tells Pegasus Mail to create special log files that show the entire exchange of information between it and the servers it connects to. Each session will be created in a file called TCPxxxx.WPM in your home mailbox directory (the "xxxx" is replaced by four digits). Creating session logs will slow down the performance of your system somewhat, and you should be aware that any username and password information exchanged between Pegasus Mail and the server will be shown in the log, *even* if you use SSL to secure the connection. Session logs are primarily useful if you need to debug a problem between Pegasus Mail and one of the servers it connects to - you should enable the option only on instructions from a system administrator or from Pegasus Mail technical support. [ Technical note: this control has the same effect as using a "-Z 32" commandline switch when you run Pegasus Mail ]

You can now try again to send the mail and then look at the resulting TCP/IP debug file.  Review of this file will tell you if the mail is getting to the SMTP host without error.  If your mail is getting to the SMTP host but is not getting delivered to the receiver I can only suspect that somehow the mail is getting deleted.

If the mail is actually getting to the SMTP host and not to some proxy in between then there is very little you can do except change SMTP hosts.

You might post one of the session logs here, especially the very first part to show if a proxy is invloved.

I can provide you a SMTP host to test this if you wish.  Get in touch with me directly at support@tstephenson.com.

Thomas,

Did as you suggested, and activated logging.

The log shows clearly that there is no problem with mail leaving my machine. Once the message body has been transmitted, the server closes the connection. The final entry in the log is "Connection closed normally at Tue, 29 May 2007 08:42:16" - presumably final words from Pegasus...

The ISP server does identify itself as a relay, but the designation has the look one might expect from one of a bank of communicators forming the infrastructure of the 'server' entity and is located at my ISP..

As far as I am concerned it is now down to my ISP. (The next battle will be to persuade their accounts people to adjust this month's charges...).

Thanks for the tip, and the ammunition for upcoming discussions with my ISP. It is also a relief to know that good old Pegasus Mail continues to work as reliably as it has always done.

   ---oOo---

As far as I am concerned, this thread can now close, with my grateful appreciation to all who took an interest.

However, I see there may be some ongoing interest in related areas, so I will leave it to someone else to close the thread.
 

I shall have to drink more coffee before forum ventures in the mornings.

I have just noticed from AndyW's log report that he is with the same ISP as myself. His contact was with 'relay-1', mine was 'relay-3' . I am also in the UK..

If there is a way of checking whether a message is still stuck on an ISP's server, I would be interested. When there is no reasonably prompt response to a message, it would useful to know how far it has travelled towards its destination.

I am not concerned with normal or trivial mail, but with the rare occasions when it is important to know that mail has reached the intended recipient. If the recipient chooses not to respond to your message that is OK - but it would be useful to know that is the case, rather than wondering forever about where it got to in the pipeline.

 Thanks again for your help.

If you do not have a fixed IP address with a rDNS record of some sort then I think you'll find that you'll be bounced by many ISPs when sending directly from your PC.  That's why many people cannot use MercuryE direct delivery.  I'd recommend that yuo get a GMail account and use that server for delivery.