HelenJ said:
You: Well *all* means that you also *changed* the mail server settings.
So
now
you are using different mail servers which means you changed to which
e-mail
accounts you are connecting. You will need to use the login credentials
for
those new accounts. The old account's login credentials won't work for
the
new accounts.
Me: Thanks - but yes I am aware of that - the connections to my mail
servers
work fine, and the password(s) are correct
Have you tried logging in using the webmail interface to your account? That
would show if you are using the correct login credentials (username and
password).
You: Does *just* clicking on the OK button work? That is, if you do NOT
change
the login credentials, do you connect okay after just clicking OK?
Me: YES!
Well, then the login credentials are correct but are not getting sent to the
mail server correctly or you aren't even getting connected to the mail
server.
You: Have you tried disabling e-mail scanning in your anti-virus software?
Me: I really don't see why this would make any difference and I don't
want
to lay myself open this way
Anti-virus scanning interferes with e-mail programs. When receiving mails,
the anti-virus program intercepts the mail to interrogate its contents to
check for pests. During the interrogation, the mail has yet to be delivered
to the e-mail program that requested it. If the AV program takes too long
to interrogate the e-mail, the e-mail client errors with a timeout because
it figures the mail server never delivered the mail that it just requested.
Some AV programs will send a bogus X-header to the e-mail client during the
interrogation to keep the e-mail client happy and prevent it from timing
out. On sending e-mails, again the AV program may be interrogating the
contents of the mail and delays when it gets from the e-mail client to the
mail server. This delay can cause problems.
E-mail scanning adds no extra layer of protection from pests *if* you have
running the on-access scanner included in the anti-virus software. The
on-access scanner checks for pests when files are created or modified. When
you download your e-mails, obviously a file gets modified by the addition of
the content of those new e-mails. E-mail scanning duplicates the
functionality already provided by the on-access scanner. Even Symantec had
an article saying that e-mail scanning duplicated the protection of the
on-acces scanner and noted that disabling e-mail scanning did not reduce
protection. There is no additional protection afforded by scanning of
inbound e-mails. There is only one protection afforded by scanning of
outbound e-mails *if* the AV program includes the feature, and that is to
check if you are sending too many mails without the use of user interraction
(i.e., you are infected with a mailer trojan) to prevent you from spamming.
If you keep your AV software up to date and run scans using several
anti-malware programs, the risk is very low that you are infected and need
any anti-spamming protection afforded by scanning and monitoring of your
outbound mails.
Disabling e-mail scanning within your anti-virus program is NOT the same as
disabling the on-access scanner in your anti-virus program. You will still
be protected.
You: What type of connection do you have to the mail server?
Me: I am on broadband with 4 computers all connecting (through a
rounter? -
not too good on networks - but there is nothing fancy - just peer to
peer) -
none of the others (running a variety of Oultook versions) are having any
problems - so I think it is my machine that is doing something strange
I listed several types in my question (which you snipped out). I asked
which TYPE of connection you have because some types can have different
problems than other types of connections. For example, you said that you
have a broadband connection but that could be via DSL modem, cable modem, or
satellite transmission. For a DSL connection, an idle session will timeout
resulting in a disconnect from your ISP. You won't know about the
disconnect. It *should* only take less than half a second for the session
to be reestablished should you generate traffic directed to or through your
ISP, but sometimes the session reconnect fails. In whatever device is
connected to the DSL modem, configure the PPPoE settings to enable the Keep
Alive option. When there is no traffic getting sent out, this will send
some traffic so that your ISP doesn't see the session as idle and kill it.
If there is too much of a delay in getting packets from your host to the
mail server, that delay can cause connection errors to the mail server.
Packets get lost which means they have to be resent. Having to retry
sending the same packets that were sent before means it takes longer to get
all the packets, and that equates to delay for retrying all the lost
packets. The more lost packets, the more delay, the more likely you incur a
connection problem (to establish or retain). Try the following command in a
DOS shell:
ping -n 100
www.yahoo.com
Yahoo will respond to pings. The default number of pings is only 4 and that
is not a large enough sample size to determine how many packets may be
getting lost in the connection between your computer or NAT router through
the DSL/cable/analog modem to the ISP's host. A hundred packets should be
large enough without it extending the test time for too long. See how many
packets are lost, as a percentage, from all the pings. The more that are
lost, the more of a delay there is due to having to resend the lost packets.
You can call you ISP to check the quality of your broadband connection (if
dial-up, the telco will not guarantee quality beyond the low level needed
for voice communications which is far below what you need for data
communications). They can check the signal strength. That does NOT tell
you how many packets are getting lost and your ISP won't or can't test for
that. If you see something higher than 8% packet loss then bitch to your
ISP about it. I start seeing e-mail problems at just 4% packet loss, like
slow downloads obviously. I've seen some e-mail clients start to balk at 8%
loss. The web browser won't balk even at much higher packet loss because it
just uses a timer (I think IE will wait up to 5 minutes). So being able to
browse okay does not equate to being able to e-mail okay.
You: You can enable the troubleshooting log in Outlook to see the
connection
attempt and what commands, if any, have been sent from Outlook to the mail
server.
Me: you don't say how to do this - but I think it will just show that it
has
asked for the password won't it?
I didn't mention where to find the option because it is an option that can
be found by digging through them. I prefer to explain and hint without
doing the handholding until the user reports that they have tried and
failed.
POP3 is a lousy protocol regarding error reporting. It has all of just 2
statuses that can returned from a command sent by the e-mail client to the
mail server: OK and ERR. Well, there are *lots* of different ways to error
but only a single ERR code. A comment may follow the ERR status string but
there is no standardization on what that commentary string will contain so
there is no way to use it to test on what kind of error caused the problem.
The e-mail client has no way to know what type of error occurred. Could
have been the login credentials were invalid. Could be the mail server
complains that the e-mail client is sending commands in the wrong order.
Could be lots of reasons, and yet just a lone ERR status gets returned for
them all. Since the e-mail client has no means of differentiating the cause
of the error, it just assumes the login must've failed and shoves a login
screen when, in fact, the login may have completed okay but some other error
occurred or you didn't even get connected to send the login credentials.
Shoving a login prompt in your face is bogus because the e-mail client has
nothing else it could do in the case of an error.
That is why logging will show you when the error occurred. The error status
usually includes a commentary string that YOU might understand but is
useless to the e-mail client.
You never mentioned WHICH version of Outlook that you use. In OL2002, go
under the Tools -> Options -> Other -> Advanced menu and enable
troubleshooting logging. This creates a logfile in the temp directory of
your profile path (%userprofile%\temp\opmlog.log). After enabling the
logging option, exit Outlook, delete the opmlog.log file if it exists, enter
Outlook and have it poll just ONE account (so the log isn't a mix of
commands sent to multiple e-mail accounts that are getting polled
concurrently by Outlook).
