Avoiding a "Bogus HELO" error

D

Dan

Hi,

My outgoing messages get tagged as spam by many spam filters because of
"Bogus HELO" headers.

I am using an ISP's SMTP server for sending mail; is there any way to
configure TCP/IP on my end (Windows XP Pro) to solve the problem?
Basically, I need my machine name to show up as a fully-resolved name, not
just the single-word name that I've assigned to it locally.

Thanks,
-dan
 
L

Lanwench [MVP - Exchange]

Dan said:
Hi,

My outgoing messages get tagged as spam by many spam filters because
of "Bogus HELO" headers.

I am using an ISP's SMTP server for sending mail; is there any way to
configure TCP/IP on my end (Windows XP Pro) to solve the problem?
Basically, I need my machine name to show up as a fully-resolved
name, not just the single-word name that I've assigned to it locally.

Thanks,
-dan

This is all controlled by your mail server, not your client. Talk to your
ISP. HELO/EHLO is part of SMTP communication - and your computer isn't
issuing the command; your ISP's SMTP server is.
 
D

Diane Poremsky [MVP]

Your isp's SMTP is the one that is misconfigured, it should add their FQDN
to the header. The best you can do is configure windows xp pro's SMTP to
forward the mail to your ISPs server and configure it to add a FQDN.

--
Diane Poremsky [MVP - Outlook]
Author, Teach Yourself Outlook 2003 in 24 Hours
Coauthor, OneNote 2003 for Windows (Visual QuickStart Guide)
Author, Google and Other Search Engines (Visual QuickStart Guide)



Join OneNote Tips mailing list: http://www.onenote-tips.net/
 
B

Brian Tillman

Lanwench [MVP - Exchange]
This is all controlled by your mail server, not your client. Talk to
your ISP. HELO/EHLO is part of SMTP communication - and your computer
isn't issuing the command; your ISP's SMTP server is.

Not true. When your PC wishes to send mail, it's using the SMTP protocol to
connect to the ISP's server and the first thing your PC does is issue a HELO
command to the server. Otherwise the server wouldn't respond.

That said, it would be unusual for the ISP's server to require a fully
qualified domain name.
 
L

Lanwench [MVP - Exchange]

Brian said:
Lanwench [MVP - Exchange]
This is all controlled by your mail server, not your client. Talk to
your ISP. HELO/EHLO is part of SMTP communication - and your computer
isn't issuing the command; your ISP's SMTP server is.

Not true. When your PC wishes to send mail, it's using the SMTP
protocol to connect to the ISP's server and the first thing your PC
does is issue a HELO command to the server. Otherwise the server
wouldn't respond.

<smacks forehead> In rereading I see that I didn't phrase my reply well at
all; you're quite right.

However, I still think this is more likely a problem with the SMTP server
the OP is
sending mail through - because that server is issuing the HELO
command to the recipients' servers; Outlook isn't talking to them directly,
and any header information involving the client-to-ISP communication won't
be the one a spam filter is looking at as it isn't the newest/last.
That said, it would be unusual for the ISP's server to require a fully
qualified domain name.

Yep...and Outlook isn't talking directly to the recipient's server, isn't
getting rejected when sending mail through it (the mail is being delivered),
so I'd still suggest that he contact his ISP.

Thanks for replying with the correction. I don't think I had had enough
coffee yesterday morning!
 
V

Vanguardx

Dan said:
Hi,

My outgoing messages get tagged as spam by many spam filters because
of "Bogus HELO" headers.

I am using an ISP's SMTP server for sending mail; is there any way to
configure TCP/IP on my end (Windows XP Pro) to solve the problem?
Basically, I need my machine name to show up as a fully-resolved
name, not just the single-word name that I've assigned to it locally.

Thanks,
-dan

If you are using the same ISP for e-mail as you used to post this
message (Comcast), what about Comcast's add of the Received header is
considered bogus? When I send a message using Comcast's SMTP server,
the first Received header (the one it added) look like:

Received: from <myHostname>
(c-<myIPaddrs>.<state>.client2.attbi.com[<myIPaddrs>])
by comcast.net (sccrmhc11) with SMTP
id <someAlphanumericString>
(Authid: <myAccountName>);
Wed, 6 Oct 2004 17:13:32 +0000

I'm one of those AT&T customers that got forcibly migrated to Comcast
when Comcast bought out the broadband services of AT&T. That's why
attbi.com is still listed for hosts in the route (I keep asking they
change this but they are lazy). The <myHostname> is whatever the e-mail
client claimed it was in the HELO command to the SMTP server. I can't
think of why spam filters would trigger on the hostname of the sending
client. According to RFC 2821 for the HELO or EHLO commands:

"The argument field contains the fully-qualified domain name of the SMTP
client if one is available. In situations in which the SMTP client
system does not have a meaningful domain name (e.g., when its address is
dynamically allocated and no reverse mapping record is available), the
client SHOULD send an address literal (see section 4.1.3), optionally
followed by information that will help to identify the client system."

Well, since you are the customer getting a dynamically assigned IP
address from Comcast's DHCP server then you don't have a FQDN to report
in the HELO command. Might be different if you had a registered domain
name and were assigned a static IP address from your ISP. Notice that
the RFC says an address literal (dotted decimal) *SHOULD* be used. That
doesn't make it a requirement and most times an alphnumeric string is
used which is the local hostname (probably because the sender doesn't
want to divulge their internal IP addressing scheme or reveal their
internal IP addresses). The stuff inside the parenthesis (i.e.,
"(ipname [ipaddrs])") at the end of the "from" section of the Received
header are added by the receiving SMTP server to identify who really
connected to it (and I don't think there really is a standard that
dictates the format of this SMTP server added sender information).

Maybe changing your hostname would help. The spam filter shouldn't
trigger on it but maybe it does, so using a hostname of "SPAM" would be
a bad idea.
 
D

Diane Poremsky [MVP]

Keep in mind that RFC 2821 deals with MSAs and MTAs (servers). MUAs
(clients) are covered by RFC 2476 if I recall correctly.

--
Diane Poremsky [MVP - Outlook]
Author, Teach Yourself Outlook 2003 in 24 Hours
Coauthor, OneNote 2003 for Windows (Visual QuickStart Guide)
Author, Google and Other Search Engines (Visual QuickStart Guide)



Join OneNote Tips mailing list: http://www.onenote-tips.net/


Vanguardx said:
Dan said:
Hi,

My outgoing messages get tagged as spam by many spam filters because
of "Bogus HELO" headers.

I am using an ISP's SMTP server for sending mail; is there any way to
configure TCP/IP on my end (Windows XP Pro) to solve the problem?
Basically, I need my machine name to show up as a fully-resolved
name, not just the single-word name that I've assigned to it locally.

Thanks,
-dan

If you are using the same ISP for e-mail as you used to post this message
(Comcast), what about Comcast's add of the Received header is considered
bogus? When I send a message using Comcast's SMTP server, the first
Received header (the one it added) look like:

Received: from <myHostname>
(c-<myIPaddrs>.<state>.client2.attbi.com[<myIPaddrs>])
by comcast.net (sccrmhc11) with SMTP
id <someAlphanumericString>
(Authid: <myAccountName>);
Wed, 6 Oct 2004 17:13:32 +0000

I'm one of those AT&T customers that got forcibly migrated to Comcast when
Comcast bought out the broadband services of AT&T. That's why attbi.com
is still listed for hosts in the route (I keep asking they change this but
they are lazy). The <myHostname> is whatever the e-mail client claimed it
was in the HELO command to the SMTP server. I can't think of why spam
filters would trigger on the hostname of the sending client. According to
RFC 2821 for the HELO or EHLO commands:

"The argument field contains the fully-qualified domain name of the SMTP
client if one is available. In situations in which the SMTP client system
does not have a meaningful domain name (e.g., when its address is
dynamically allocated and no reverse mapping record is available), the
client SHOULD send an address literal (see section 4.1.3), optionally
followed by information that will help to identify the client system."

Well, since you are the customer getting a dynamically assigned IP address
from Comcast's DHCP server then you don't have a FQDN to report in the
HELO command. Might be different if you had a registered domain name and
were assigned a static IP address from your ISP. Notice that the RFC says
an address literal (dotted decimal) *SHOULD* be used. That doesn't make
it a requirement and most times an alphnumeric string is used which is the
local hostname (probably because the sender doesn't want to divulge their
internal IP addressing scheme or reveal their internal IP addresses). The
stuff inside the parenthesis (i.e., "(ipname [ipaddrs])") at the end of
the "from" section of the Received header are added by the receiving SMTP
server to identify who really connected to it (and I don't think there
really is a standard that dictates the format of this SMTP server added
sender information).

Maybe changing your hostname would help. The spam filter shouldn't
trigger on it but maybe it does, so using a hostname of "SPAM" would be a
bad idea.

--
_________________________________________________________________
******** Post replies to newsgroup - Share with others ********
Email: lh_811newsATyahooDOTcom and append "=NEWS=" to Subject.
_________________________________________________________________
 
V

Vanguardx

Diane Poremsky said:
Keep in mind that RFC 2821 deals with MSAs and MTAs (servers). MUAs
(clients) are covered by RFC 2476 if I recall correctly.

The e-mail client uses the same SMTP commands that are used between SMTP
servers. The role of the MSA has always seemed a bit vague to me, more
for use in an environment where the e-mail client can't supply all the
required SMTP info. Since my e-mail client is not using port 587 then
it really doesn't look like RFC 2476 applies.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top