Unknown Email Issue

[ABLE1]

This may or may not be a OE issue but I thought I would ask here
first to hopefully get some input.

I have an individual that can send me a email. It comes into my
XP-Pro w/OE just fine.

Then I do a Reply to their email. It bounces back in a few seconds
as "Undeliverable".

I then check the email address and all looks good. I type the email
address into a new message and the same thing happens. I call and
ask that she provide me with a couple of other email address within
her organization. She sends me two and I respond to all three and
they all bounce back as "Undeliverable".

This happened about a couple of months ago. Since then I bought a
new computer for my wife, Win7 machine. She just informed me that
she had the same issue with someone she emails and that in happened
on her older XP-Pro machine with OE and still happens with the same
person on her new machine using Outlook.

So I am wondering what could be going no. I know the problem is not
necessarily on my end. Especially since it has happened on three
different machines and totally different email addresses.

And then to add a twist to this last week someone sent me a email
that I responded to. They never received my response and it never
did bounce back. I then sent him two other emails using 2 different
outgoing email addresses and neither ever showed up on his end. I
tried this twice with the same effect of nothing. I then sent to
his personal email (a .gmail account) and it went thru no problem.

Anyone have a clue where to look?? Or is this totally out of my
power to control??

Thanks,

Les

[VanguardLH]

"ABLE1" wrote:

> I have an individual that can send me a email. It comes into my
> XP-Pro w/OE just fine. Then I do a Reply to their email. It bounces
> back in a few seconds as "Undeliverable".

What happens when you compose a NEW e-mail (not a reply) and YOU specify
their e-mail address?

What happens when you create a NEW e-mail (not a reply) and you use the
e-mail address the sender put in the From header?

What happens when you create a NEW e-mail (not a reply) and you use the
e-mail address the sender put in the Reply-To header?

When you reply, your client uses the Reply-To header to determine to
where your reply gets sent. This may not be the same as the e-mail
address in the From header in the e-mail that you received from that
sender. They may have an invalid e-mail address in the Reply-To header.
That means a misconfiguration on THEIR end in their e-mail client.

> I then check the email address and all looks good. I type the email
> address into a new message and the same thing happens. I call and
> ask that she provide me with a couple of other email address within
> her organization. She sends me two and I respond to all three and
> they all bounce back as "Undeliverable".

Just what did the NDR (non-delivery report) e-mail that you got back
actually say?

> This happened about a couple of months ago. Since then I bought a new
> computer for my wife, Win7 machine. She just informed me that she
> had the same issue with someone she emails and that in happened on
> her older XP-Pro machine with OE and still happens with the same
> person on her new machine using Outlook.

Could be you and those other senders are on a blacklist employed by her
e-mail provider. They're refusing to accept e-mails from your domain.
Some public DNSBLs (DNS blacklists) are SpamCop and Spamhaus. Again,
the details in the NDR that you receive might enlighten the cause for
rejection of your e-mails - and also clarify if the NDR was sent by your
own e-mail provider or was a rejection by the recipient's e-mail server.

> So I am wondering what could be going no. I know the problem is not
> necessarily on my end. Especially since it has happened on three
> different machines and totally different email addresses.

Certainly looks on the surface that you are specifying invalid e-mail
addresses. You're getting the domain wrong. Or maybe you're getting
the username wrong in the e-mail address. Or maybe you're using an
invalid syntax for an e-mail address.

One way to test is a username exists at a domain for an e-mail provider
is to do the SMTP handshaking to connect your client (or server) to
their SMTP server, establish an e-mail session, and then do a RCPT TO
command as if you were going to start sending an e-mail to there. That
just specifies to whom your e-mail should go. A following DATA command
actually sends your message - so just do RCPT-TO without a following
DATA command to see if the specified username exists there. The RCPT-TO
command specifies the recipient at the target SMTP server. If you
cannot connect to the target SMTP server then you are using an invalid
domain. If you can connect then you got to an SMTP server (which may or
may not be for the recipient) and then you can send a "RCPT TO
<recipientemail>" to see if there is an account there with that
username. Of course, not many users want to figure out how to issue
SMTP commands to establish an e-mail session with a server, so there are
online utilities to do the same, like:

http://www.ip-address.org/verify/email-checker.php
http://www.email-unlimited.com/tools/verify-email.aspx

Those check if the domain exists and, if so, if there is an MX record on
that domain (to identify the SMTP server there, if there is one), and
establishes an e-mail session and, if that works, sends the RCPT-TO
command to see if the receiving e-mail server accepts it (meaning there
is an account there by that username), and then terminate the e-mail
session (i.e., don't follow with DATA since the intent is not to send a
message but just verify the recipient is known there). This works with
many SMTP servers. There are some that accept all e-mails and do no
verification during the e-mail session. They accept all e-mails, end
the e-mail session, and then determine if the e-mail is deliverable. If
not, they use the return-path headers in the e-mail to send back an NDR;
however, the return-path headers were specified by the sender so if they
are wrong (as in the case of spam) then the server sends its NDR to the
wrong return address. A properly configured and operating SMTP server
will validate the recipeint DURING the e-mail session when the RCPT-TO
command is sent, not sometime after the e-mail session has ended.

> And then to add a twist to this last week someone sent me a email that
> I responded to. They never received my response and it never did
> bounce back. I then sent him two other emails using 2 different
> outgoing email addresses and neither ever showed up on his end. I
> tried this twice with the same effect of nothing. I then sent to his
> personal email (a .gmail account) and it went thru no problem.

Did you configure your anti-virus (AV) software to scan your outbound
e-mails? Why? Scanning (inbound or outbound) is superfluous. The same
on-access AV scanner used to monitor files on your host when they are
created or modified is the same one used to scan your incoming and
outgoing e-mails. E-mail scanning affords no more protection than the
on-access scanner. It only changes when an infected e-mail gets
detected (during e-mail transmission versus later when you try to
extract an attachment in an incoming e-mail). Outbound scanning is very
superfluous since your AV scanner should've already verified your files
are not infected. If it found an attachment that was infected on an
outgoing e-mail, why didn't it detect that infected file when you opened
it to attach to your outbound e-mail?

Some AV programs check e-mail traffic on-the-fly. They interrogate the
traffic packet(s) at a time to check for malware. There is a slight
delay between client and server due to this interrogation but the delay
is usually pretty short. I say "usual" because one problem incurred
from interrogation is added delay in delivery (from client to server or
from server to client) that can cause timeouts which can cause various
symptoms (client thinks the e-mail handshaking failed to establish a
mail session with the server, client thinks server has stalled
delivering an e-mail, etc). However, in this transparent proxy method
of interrogating your e-mail traffic, the status your e-mail client gets
from commands it issues to the server are those sent by the server.
There is no masking of status sent back by the server for commands it
received from your client.

Another type of AV e-mail scanner completely interferes with the
connection between your client and the server. Your client never really
connects to the e-mail server. The server never really connects to your
client. Instead your client connects to the AV's proxy which pretends
it is the server. Your e-mail client goes through the sending process.
The AV proxy accepts your e-mails and returns a good status. The
sending worked okay between your client and their proxy. After that,
your client is no longer connected to the AV proxy. That e-mail session
has ended. Your client was also never connected to the real e-mail
server, either. Then they interrogate the e-mail. If interrogation
passes, their proxy pretends it is the client and connects to the real
server to complete the e-mail transmission. Here's the rub: if the
e-mail session between the fake client (the AV proxy) and the real
e-mail server hits a snag (an error occurs), only the AV proxy knows
about it. Your real client isn't involved so it never knows there was
an e-mail error at the server end.

- your client establishes session with AV proxy
your client --> AV proxy (pretending it's the server)
e-mail session is over for your client
- AV proxy inspects e-mail
- AV proxy establishes session with real e-mail server
AV proxy (pretending it's the client) --> real e-mail server
server issues an error during e-mail session
only the AV proxy knows about the error (your client isn't connected)

That means you have to go look in your AV program's logs to see if it
received an error from the server during its fake client connection to
the real e-mail server. Your client won't know anything about that
error. As far as your client is concerned, the SMTP session had no
error because your client only connected to the AV proxy when it was
pretending to be the server.

If you have the latter type of e-mail scanner in your AV program, you
must go look at its logs to determine if there are problems with any of
your outbound e-mails. That's a pain plus you have to remember to go
check unless the AV program happens to popup an alert about the error
during its e-mail session (when it pretended it was your client) with
the server. If your AV program works this poor way, uninstall it and
get a better AV program; however, there is still no reason to waste the
overhead scanning outbound e-mails for malware (since the on-access or
real-time AV scanner should have already caught an infected file on your
host) and there's no reason to scan inbound e-mails (since any
attachments in them mean having to create new files to extract them at
which point your AV's on-access scanner will find the malware).

[ABLE1]

I just printed this out so I can digest all the extra input.

Will respond later.

Thanks,

Les



"VanguardLH" <V...@nguard.LH> wrote in message
news:k0kqu2$2nk$1...@news.albasani.net...

[Steve Cochran]

One way you can rule out OE or some of the issues Vanguard raised is to
check via webmail if you have that option. If you still get the rejected
messages then it is likely downstream from your machine(s).

steve

"ABLE1" <royboy...@somewhere.net> wrote in message
news:01AXr.310416$xK2.2...@en-nntp-11.dc1.easynews.com...

[ABLE1]

Now that I am converting to Thunderbird I am evaluating to see if
some of my issues are going away. So far so good except for the
kick back of the one email issue. Still seems to be happening even
with Thunderbird and after some changes with Comcast. I am starting
to think it is something that is out of my control.

I can send a message from the Comcast email webpage and it goes thru
with no kick back. But out of my system either OE or TB it kicks
back. It would seem to me that it has something to do with a server
some where with the wrong protocols or settings. Again I don't
think I can do much about that.

Les



"Steve Cochran" <scoc...@oehelp.com> wrote in message
news:k0oofj$9d$1...@speranza.aioe.org...

[Bruce Hagen]

"ABLE1" <royboy...@somewhere.net> wrote in message

news:ekTXr.220894$iq1....@en-nntp-12.dc1.easynews.com...

Comcast settings have changed since the merge with Xfinity.

Configure Outlook Express for XFINITY email
http://customer.comcast.com/help-and-support/internet/configure-outlook-express-xfinity-internet/

Configure Outlook Express to work remotely
http://customer.comcast.com/help-and-support/internet/configure-outlook-express-to-work-remotely/

Configure Windows Mail for XFINITY email
http://customer.comcast.com/help-and-support/internet/configuring-windows-mail-xfinity-email

Configure Windows Live Mail 2011 for XFINITY email
http://customer.comcast.com/help-and-support/internet/configure-windows-live-mail-2011-for-xfinity-email

--
Bruce Hagen
MS-MVP Oct. 1, 2004 ~ Sept. 30, 2010
Imperial Beach, CA

[VanguardLH]

"ABLE1" wrote:

> I can send a message from the Comcast email webpage and it goes thru
> with no kick back. But out of my system either OE or TB it kicks
> back. It would seem to me that it has something to do with a server
> some where with the wrong protocols or settings. Again I don't
> think I can do much about that.

Actually *showing* the NDR (non-delivery report) e-mail or the error
message or status that you get would help immensely. A highly vague
description of "kick back" provides no information on which to diagnose
the problem.

Vaguely described problems result in vaguely focused solutions.

[ABLE1]

Comcast Tech said that the outgoing and incoming ports are
different. 110 and 25 are going to be turned off sometime soon.
Changed to new, no help. Said it appears like some server is
tagging my email as Spam or some kind of black list. Sent the
trouble ticket to "national" Should hear something by
Wednesday................................................

Technology is great when it works!!!

Les





"Bruce Hagen" <B...@nospam.invalid> wrote in message
news:k0ovti$bq1$1...@dont-email.me...

[ABLE1]

Ok, This is becoming a big challenge for the Comcast Tech's. So far
I have tried to send from my computer and my iphone and both email
kicked back with the message below. The only time a email does not
is if I send it from the Comcast.net webpage.

The last Comcast Tech checked and verified that the email was good.
She also suggested that since they do not know what the problem
could be that I should use the webpage to email to this person.
Dhuuuuuuuu??

I have changed the emails in the below for obvious reasons.

It would seem that I am getting a education on email stuff that I
didn't know or needed to know up to this point. Once this is
resolved (or not) I will have to flush all this information to make
room for the better things of life.

Thanks for look and trying to assist.

Les
=============================================================
Email rejection or NDR (or kick back) notice below.
=============================================================
This is an automatically generated Delivery Status
Notification.

Delivery to the following recipients was aborted after 1 second(s):

* ZZ...@ZZZZZZZZZZ.com


Reporting-MTA: dns; qmta13.westchester.pa.mail.comcast.net
[76.96.59.243]
Received-From-MTA: dns; omta14.westchester.pa.mail.comcast.net
[76.96.62.60]
Arrival-Date: Sun, 19 Aug 2012 21:30:05 +0000


Final-recipient: rfc822; ZZ...@ZZZZZZZZZZ.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 554 Denied
[ada51305.0.238683.00-2398.304750.p02c11m094.mxlogic.net] (Mode:
normal)
Last-attempt-Date: Sun, 19 Aug 2012 21:30:06 +0000


Received: from [142.138.0.27] ([144.34.161.49])
by omta14.westchester.pa.mail.comcast.net with comcast
id olW41j00G1w4mue3alW4nm; Sun, 19 Aug 2012 21:30:04 +0000
X-Authority-Analysis: v=2.0 cv=HpbB7TvS c=1 sm=1
a=cPcG5zJOZ8cgeonCM5Csrg==:17 a=rl5eUP2J6s4A:10 a=kj9zAlcOel0A:10
a=HY-WamAUOGoA:10 a=C_IRinGWAAAA:8 a=gPyaH_DCodoimrd6YzsA:9
a=CjuIK1q_8ugA:10
a=cPcG5zJOZ8cgeonCM5Csrg==:117
Subject: Testing from my phone
From: ABLE_1 <xxxxxxx.comcast.net>
Content-Type: text/plain;
charset=us-ascii
X-Mailer: iPhone Mail (9B206)
Message-Id: <E9B2D2F5-788B-4E36...@comcast.net>
Date: Sun, 19 Aug 2012 17:30:00 -0400
To: "ZZ...@ZZZZZZZZZZ.com" <ZZ...@ZZZZZZZZZZ.com>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

"VanguardLH" <V...@nguard.LH> wrote in message

news:k0pdln$6gd$1...@news.albasani.net...

[VanguardLH]

Is the recipient another Comcast user with a Comcast e-mail address? Or
is the recipient (whether a Comcast user or not) using an e-mail service
outside of Comcast (e.g., Hotmail, Yahoo, Gmail)? Is the recipient's
e-mail address a company e-mail address (i.e., you're specifying an
e-mail address at a company for one of their employees)?

The reasons why I ask are:
- Sometimes internal routing for e-mails between Comcast users (sender
is Comcast and recipient is Comcast) has some hiccup. In that case,
and because I'm the sender and can ask for help only on my account:
o In my local e-mail client, I move all Inbox items into another
folder (create a temp one for now). I empty the Outbox folder
(which normally should be empty already). I empty or move out any
items in the Drafts folder.
o I exit my local e-mail client so it won't be doing any mail polls
during the following steps.
o Using the webmail client to my e-mail account, I empty or move out
all items in the Inbox folder. Any left in the Drafts folder are
probably too old so I delete those.
o I call the e-mail provider's tech rep to reset my account.
* If they ask for your password, just tell them to reset it (and ask
them what it is) rather than give them your real password. They
don't need your real password but can just reset it to anything
they want. After you're done with them resetting your account, go
in using their password and set it back to what you were using
before (although this would be a good time to review if you are
using a *strong* password on your account).
o After they have reset the account, and after you use the webmail
client to access your e-mail account to change back to your old
password (so it matches the one you recorded in your local e-mail
client), see if you can now send out e-mail messages.
- For internal routing, their SMTP server (on the boundary of the
network that connects outside to other SMTP servers) isn't used when a
Comcast user sends e-mail to another Comcast user. It's routed around
using their internal SMTP servers. There's no fix until they realize
the problem to fix it. So is the problematic recipient another
Comcast user using their Comcast e-mail address? Or are they using a
non-Comcast e-mail address to which you send them your e-mails?
- I've had companies put my e-mail service on their blacklist. I had a
buddy at Unisys whose blacklisting didn't tag my e-mails as spam and
put it in his Spam folder but instead never delivered it to his
mailbox. They also *never* sent back an NDR. If blacklisted, e-mails
went into a black hole. This is quite rude because the recipient
doesn't get the e-mail (even to see if it went into his Spam folder)
and the sender doesn't get notified their e-mail was rejected. I was
sending from Yahoo at that time and getting Yahoo-sourced e-mails to
Unisys employees was very unreliable at that time (this lasted for
several years). The error you see doesn't specifically indicate that
the receiving mail server had you blacklisted; however, the 554 error
is a vague status that can mean many things. Without an accompanying
comment that explains their reason for generating a 554 error, you
won't really know why they rejected your e-mail.
- Which ports are configured in your local e-mail client or in your
smartphone for connecting to your ISP's mail servers? For Comcast,
you should be using:
POP3: 995, SSL enabled
SMTP: 465, SSL enabled
For Outlook, under the Outgoing Server tab in the account definition,
do *NOT* enable SPA (Secure Password Authentication). Comcast doesn't
support it.
Don't use port 25 for SMTP even if Comcast says it is okay. If they
see probably spam behavior on your end, they'll disable port 25 across
their network for your connection. I've also seen port 25 simply go
dead even when their techs say to use it but 995+SSL still works. Yet
I don't think a port misconfiguration is your problem. If you were
using a port on which the server wouldn't listen then your client
would report that it couldn't connect. Getting an NDR means you got
to the server. I only mention this to ensure you use reliable ports.
- Another trick I use in most e-mail client is to NOT reuse the POP
login for authenticating use of their SMTP server. The general setup
assumes that your client will first perform a POP session to retrieve
e-mails from your account. The following SMTP session reuses the
login credentials from the prior POP session; however, the SMTP
session must start within some short time after the *start* of the POP
session. If you receive big e-mails, use AV to scan your e-mails
which delays handling the e-mails during the POP session, or for some
reason the POP session lasts too long, the login expires for the
subsequent SMTP session which then fails. Instead of reusing the POP
credentials for the SMTP login, configure your e-mail client to use a
separate login to use their SMTP server. You configure POP to login
using your credentials (username + password). You configure SMTP to
do its own login using the same credentials. In Outlook, under the
Outgoing Server tab when defining an e-mail account, select "Log on
using" and specify the same username and password you used for the POP
login. Have your client login for both POP and SMTP, not just for POP
and hope the server will still accept the old POP login for the
following SMTP session.
- Anti-virus (AV) programs interfere with the operation of e-mail
clients. Besides delaying transmission of e-mail traffic (in or out)
that causes delays, they can alter the content of e-mails and they may
even pretend they are the endpoint in the connection rather than pass
the e-mail traffic through while interrogating it. If they pretend
they are the endpoint, your e-mail client isn't connecting to the real
e-mail server but instead to a local proxy for the AV program. Later
your AV program pretends it is the client and connects to the real
e-mail server to complete the transmission. However, if there is an
error between the AV proxy and the real e-mail server, your e-mail
client won't ever know about it. You have to inspect the AV program's
logs to see if it got an error in its SMTP session with the real
e-mail server.
- For Hotmail, Gmail, or Yahoo (and other freebie providers), I have
seen problems in getting e-mails delivered to them. Hotmail even had
a writeup for postmaster on how best to ensure e-mails from their
servers would get accepted by Microsoft's Hotmail service. This
writeup is old so I suspect Comcast has already addressed those
issues. Also, senders didn't always get an NDR back from Hotmail when
Hotmail decided to bit bucket a received e-mail. The recipient never
got a copy (in their Spam folder) and the sender never got back an
NDR. Poof, just gone. However, what I have seen is that one e-mail
provider has problems getting their e-mails accepted by another e-mail
provider. The user can't do anything about the problem. The e-mail
providers have to work this out between themselves. You'll see
reports by users saying their provider isn't accepting e-mails from
some other provider and sometime later the problem just goes away (the
providers did something but the provider won't discuss it with their
customers). The tech reps you get to talked to haven't a clue about
the ongoing transmission problem between their service and another.
- Are you using anything other than printable ASCII-7 characters for the
recipient's e-mail address? It is possible that the SMTP server
accepting your outbound message with its parsing of that e-mail
address is more strict than when using the webmail client to your same
account. I have run across parsing problems on recipient e-mail
address when connecting with local e-mail client that weren't present
when using the webmail interface to the same e-mail account. That you
can use the webmail client to successfully send out your e-mail means
it is valid syntax at the receiving mail server. Not all e-mail
servers support the same level of syntax for e-mail addresses. I've
seen some that don't like multiple non-alphanumeric characters or too
many parts in the username, like joe.arnold....@domain.com.
One server may simply not accept as long a username as another. Then
are users that like to add lots of cutsy characters in their username
that cause havoc with parsers with some mail servers.

You didn't provide the headers for the NDR that you got back. So I
cannot tell if the NDR was sent by Comcast's server(s) or was sourced
from the recipient's server. I'm not sure if the headers that you did
show were in the body of the NDR or in the headers of the NDR. Please
show the NDR e-mail as:

<headers>
<space delimiter>
<body>

In Outlook, right-click on an e-mail and use the Options context menu to
see the headers to copy them into your reply. Add a blank line after
the header section and then copy the body of the NDR into your reply.
Be sure to munge out your username (and recipient's username) in your
reply; however, do not hide any non-alphanumeric characters in the
usernames as this can affect how servers parse that string. Leave the
domains since they are public info, anyway, and don't disclose anything
not already divulged in the Received headers (needed to track the
routing of the e-mail to see from where the NDR originated).

[VanguardLH]

Oops, forgot this was an OE newsgroup. In OE to get at the raw source
of an e-mail (headers + body), select an e-mail item and hit Ctrl+F3.
Copy that data (Ctrl+A) and paste in your reply so we can see both the
headers and body of the NDR message.

Also, where I said to go to the Outgoing Server tab in the account
definition in Outlook, that would be the Servers tab in OE's account
definition.

Also, anti-virus programs interfere more with OE than with other e-mail
clients. Seems OE is more timing sensitive. E-mail scanning is
superfluous so disable it in your AV program.

[Ben Myers]

"ABLE1" <royboy...@somewhere.net> wrote in message

news:vnhYr.334399$eR7....@en-nntp-16.dc1.easynews.com...

> Ok, This is becoming a big challenge for the Comcast Tech's. So far I
> have tried to send from my computer and my iphone and both email kicked
> back with the message below. The only time a email does not is if I send
> it from the Comcast.net webpage.
> The last Comcast Tech checked and verified that the email was good. She
> also suggested that since they do not know what the problem could be that
> I should use the webpage to email to this person.

<snip>

The header you posted shows "xxxxxxx.comcast.net" instead of
xxx...@comcast.net
in the "From" line. Some e-mail servers reject messages that don't have a
valid
address in that field. Make sure Outlook express is configured with your
real
e-mail address, or at least a valid one.

Ben

[ABLE1]

At this point this has consumed far too much time and I have
considered just picking up the phone and forget emailing this one
individual. That will make my already overly stressed life a little
less stressed.

Thanks for all the thinking on this topic.
I think it best to now Close the Topic.

Is it really possible to do that on Usenet??

Les



"Ben Myers" <benj...@mindspring.com> wrote in message
news:dridnU5fkagJoK_N...@earthlink.com...

[VanguardLH]

"ABLE1" wrote:

> Thanks for all the thinking on this topic. I think it best to now
> Close the Topic. Is it really possible to do that on Usenet??

No. Unless you post in a moderated newsgroup (and ask the moderator to
do something about an existing thread - but which will have no effect on
the thread of articles already peered to other NNTP servers or gatewayed
into forums), the thread remains always open. Someone years from now
who is too lazy or unobservant to notice the datestamps on the old posts
might reply and restart the discussion. You will find rare few NNTP
server that accept cancels from the originator of a post (plus they can
cancel only their posts, not those of other posters). Cancels, even if
accepted by your NNTP server, may not propagate to the other NNTP
servers to which your post got peered in the worldwide mesh network of
NNTP servers. Posters have no control over their posts in Usenet.

[ABLE1]

Vanguard,

It was meant as a joke. It would appear I did not add a :-) to the
post. Thanks for the details response.

Have a good rest of the week.