Mike @ Alleluia! said:
I have one user who receives this error on all mail leaving our
domain. Our
email and web hosting is handled by an outside service. This user
can send
successfully from her home PC, both PCs use Outlook 2003 and XP.
She is the
only user having this problem.
She had the same problem about 4 months ago, when this PC was new.
Our
hosting service only suggested decreasng the interval for her
send/receive.
That didn't solve the problem, but the problem mysteriously resolved
about a
week later. Now it is back, because due to another problem, I
restored her
profile, copying her info, deleting the old profile, recreating the
profile,
and copying her info back in.
Our hosting service says it is something on her PC, but I can't
figure out
what. Everything I can find on this is that it relates to the mail
server
relay and IP settings.
I know the case is strong that it is a local problem, but what???
"Email and web hosting is handled by an outside service" does not
state WHAT type of e-mail account this user has.
SMTP maybe? If so, does she have the e-mail account defined in
Outlook configured to authenticate to their SMTP server?
For info on off-domain port 25 (SMTP) traffic blocked to thwart spam
from spamming or infected customers, read:
http://www.commercestreet.com/Blocking_Port_25.htm
http://help.yahoo.com/help/us/mail/pop/pop-38.html
http://www.postcastserver.com/help/Port_25_Blocking.aspx
http://www.aota.net/Troubleshooting/port25.php4
http://www.spamhaus.org/faq/answers.lasso?section=ISP Spam Issues...
http://www.findarticles.com/p/articles/mi_zdewk/is_200406/ai_ziff129473
http://www.google.com/search?q=+block++"port+25"++SMTP++spam
One, some, or all of the following could have changed or are being
implemented:
- Your ISP (the network to which you connect) requires you use their
mail servers. They do not permit you crossing their network to use an
off-domain mail server over which they have no control and cannot log
e-mail traffic that uses their network. Usually this means they block
e-mail traffic using port 25 that targets an off-domain network;
however, it is also possible with protocol analyzers to detect traffic
is for e-mail and block that traffic. This is probably why Gmail
opted to force SSL connects because they use ports other than the
standard of 110 for POP3 and 25 for SMTP since everyone using Gmail is
trying to cross their ISP's network to get at an off-domain mail
server.
- The targeted mail server does not allow off-domain connections (or
requires non-standard setup of SSL, different port numbers, and/or SPA
to make off-domain connections). You are crossing your ISP's network
to reach the targeted mail servers, but to those mail servers you are
not on their network when trying to connect to those mail servers
(i.e., you are off-domain to them). You will need to check what
settings AOL requires for off-domain connections which could be
different than for on-domain connections. My ISP (Comcast) is like
that: while on their network, you connect to their mail servers using
110 for POP3 and 25 for SMTP but when coming from off their domain
then you need to use SSL, 995 for POP3, 465 for SMTP, and also use SPA
to connect to their mail servers.
- Some mail providers demand that the sending mail host have a valid
MX record in the nameserver ran by that domain. That is, the
receiving mail server gets a connection from a sending mail host that
wants to send e-mail. During the mail session, the receiving mail
server asks the nameserver of the sending mail server's domain what
are its MX (mail exchange) records. The domain should list in their
nameserver what are the valid mail hosts at that domain. Mail
originating from any other host at that domain is not authorized to
send mail from there, like from users operating their own mail servers
(often which are infected user hosts running trojan mailers). If the
sending mail host's nameserver doesn't list any MX records, or if the
sending mail host is not included in those MX records, then the
receiving mail server rejects the connection because the sending mail
host is not a valid MX host at that domain. AOL does this so maybe
your sending mail provider screwed up their MX records or forgot to
add one. Sometimes e-mail providers have reserve hosts for e-mail
that kick in when there is a problem with the primary mail host. Now
e-mail is coming from there but they forgot to add an MX record for it
in their nameserver (DNS server).
- Some e-mail providers require that you send before you receive.
Many e-mail clients receive first and then send. As a result, the
expectation is that the mail server will reuse the login for the
receive session also for the send session but the send session has to
be within a short time after the login for the receive session (not
from when the receive session ends). If there are lots of mails or
delays, too much time elapses and those login credentials for the
receive session are lost so you cannot send. The cure is to enter
your login credentials for the send session (SMTP) or to change the
order of sessions within your e-mail client (send and then receive).
Maybe I missed it but I don't see an option in OE (so it probably
isn't there in WLM) to change the order of the sessions (i.e., to
receive first and then send, or to send first and then receive).
Instead and when defining e-mail accounts in any e-mail client, I
always configure the SMTP server settings to require authentication
and then specify the same login credentials as for the POP3 server
(rather than say to reuse them). This means I have to twice enter my
login credentials: once for the POP3 configuration and again for the
SMTP configuration.
- Some e-mail providers use DNSBLs (DNS blocklists). If your mail
server gets listed and the receiving mail server uses that list then
it will reject e-mails from that sending mail server. You can use
http://member.dnsstuff.com/pages/tools.php to use their DNS Lookup
tool to check for MX records at the sender's (your) mail server
domain. Then use the Spam Database Lookup to see if your sending mail
server is blacklisted.
