Blocking by Comcast
Flakey Jakey
however, have one major problem with receiving email on two accounts.
I use NetIdentity netidentity.com) which is part of Domain Direct
(domaindirect.com) to forward email to these two accounts. The two
email addresses the netidentity forwards have been in use since I was a
flash.net subscriber or perhaps before.
I've been on Comcast as my ISP for at least 5 or 6 years and have had
only minimal problems with them. Lately, however, for aboput the past 6
months, I have had one hell of a time getting the email from the
netidentity accounts to forward to comcast. Netidentity regularly tells
me that comcast is blocking the forwarding. Within a few hours or
sometimes days, the blockage is released and the queued email comes
through. It doesn't get lost, netidentity just has to hold it until the
comcast imposed blockage is removed.
When I look at the netidentity (comain direct) atatus pages, I can see
that I am not the only comcast customer that is being blocked. WI talk
to domaindirect support people (as I have multiple times in the past 6
months), they tell me that it is comcast blockiing all emai lcoming from
domaindirect (netidentity) machines.
I sometimes can manually forward the email from the netidentiy accounts
but sometimes that doesn't work either.
So, my question is, what can I, as a user with no authority to make any
changes at either netidentity or comcast, do to avoid the necessity of
comcast blocking email coming from the netidentity accounts?
Ed Mullen
So, what does Comcast say about their blocking of those accounts? If
Netidentity is correct that Comcast is blocking them, you need to
contact Comcast to resolve the problem.
--
Ed Mullen
http://edmullen.net
It's not an optical illusion. It just looks like one.
VanguardLH
> I am a Comcast subscriber and really have few problems with them. I do,
> however, have one major problem with receiving email on two accounts.
>
> I use NetIdentity netidentity.com) which is part of Domain Direct
> (domaindirect.com) to forward email to these two accounts. The two
> email addresses the netidentity forwards have been in use since I was a
> flash.net subscriber or perhaps before.
>
> I've been on Comcast as my ISP for at least 5 or 6 years and have had
> only minimal problems with them. Lately, however, for aboput the past 6
> months, I have had one hell of a time getting the email from the
> netidentity accounts to forward to comcast. Netidentity regularly tells
> me that comcast is blocking the forwarding. Within a few hours or
> sometimes days, the blockage is released and the queued email comes
> through. It doesn't get lost, netidentity just has to hold it until the
> comcast imposed blockage is removed.
>
> When I look at the netidentity (comain direct) atatus pages, I can see
> that I am not the only comcast customer that is being blocked. WI talk
> to domaindirect support people (as I have multiple times in the past 6
> months), they tell me that it is comcast blockiing all emai lcoming from
> domaindirect (netidentity) machines.
Because Comcast is blocking on the mail server, the same one all those
customers are using to forward their e-mails. Hell, I can't even use
'dig' to retrieve A and MX records to see that they have bothered to
register their mail host(s) in their nameserver (which is often required
now as an anti-spam measure). netidentity.com's nameserver isn't
responding. Many ISPs won't accept messages from mail hosts that are
not listed in that domain's nameserver. I couldn't use Comcast's DNS to
query their nameserver to do the 'dig' so I used OpenDNS. They also
could not connect but they returned their cached information.
netidentity.com's nameserver is at ns*.mailbank.com whose domain
registrant says they are in Reno, Nevada USA and lists the registrant's
name for mailbank.com as NetIdentity. The 'dig' using OpenDNS returned
mx.netidentity.com.cust.hostedemail.com as the MX host registered at
netidentity.com as the authorized mail host there. hostedemail.com is
another private domain registration through TuCows so NetIdentity is
hiding their registration data for that domain.
I went to http://www.mxtoolbox.com/blacklists.aspx and entered the IP
address for their mail host (216.40.42.4) and it wasn't currently listed
as a spam source. However, that does not preclude a sender using that
mail host from being classified as a spam source which got that sender
added to some blacklist. Some customer under their domain might be
running their own mail host and that's the one getting blacklisted.
Some blacklists are more dynamic than others. For example, SpamCop's
listing are only for 24 hours unless a spam record gets tickled by
further detected or reported spam. I don't know what blacklists that
Comcast uses or if they might use their own.
So, you NEVER got back an NDR (non-delivery report) from either your own
e-mail provider or from Comcast notifying you of non-delivery? That
would provide more information than so far divulged to determine the
cause of the rejection.
You mention a lot of domains but never mentioned which mail server is
actually attempting to connect to Comcast to deliver your e-mail. You
mention flash.net but in all the mentions of domains you do not describe
the relationship between them. For what you've said so far, maybe
flash.net is your registered domain being webhosted by Domain Direct who
uses NetIdentity's services to provide disk space and web servers along
with their e-mail service (i.e., Domain Direct resells NetIdentity's
services). You definitely have quite the hodgepodge setup. I just did
a domain lookup on flash.net and that belongs to AT&T Internet services
so maybe that's your personal account with them and has nothing to do
with you sending e-mails from your webhosted domain (since your personal
e-mails would be originating from AT&T, not Domain Direct or
NetIdentity). Yet you say that Comcast is your ISP. So where did
flash.net come into the picture?
domaindirect.com was another registrant hiding behind Tucow's private
registration. I wasn't going to bother looking up their info or mail
host. Too many of the domains you mention are hiding. There's a clue
right there as to whether you want to trust them or not.
Working backwards, and when your e-mail scheme is all working, what is
the path for inbound e-mails to reach your Comcast e-mail account?
> I sometimes can manually forward the email from the netidentiy accounts
> but sometimes that doesn't work either.
>
> So, my question is, what can I, as a user with no authority to make any
> changes at either netidentity or comcast, do to avoid the necessity of
> comcast blocking email coming from the netidentity accounts?
You really want to use a webhosting company who resells services from
another webhosting company and where both hide behind a private domain
registration? Go do the whois lookup at the registrar (Tucows) and
you'll find that domain's registrant is Tucows. In other words, the
registrant is TuCows and TuCows is hiding who is the real registrant.
Companies that hide are not to be trusted. Maybe Comcast feels the same
way.
If Comcast is repeatedly re-adding whatever mail host you end up using
as its exit mail host from DomainDirect.com, NetIdentity.com,
hostedemail.com, or whatever connects to Comcast's SMTP mail host then
you can either complain to whomever manages that sending mail host
regarding their lack of blocking outbound spam or find somewhere else to
deliver your e-mails, like yet another forwarding service that Comcast
doesn't regularly blacklist.
It may not even be blacklisting that is the problem. If the nameserver
at the professed domain for the sending mail host doesn't list that mail
host then the receiving mail host will see it as an unauthorized mail
host at that domain. The receiver might only allow connects from a
sender that is authorized at the source domain. Many times domains
screw up when they revert to a secondary or backup mail host in that it
has not been added to their nameserver, so when they have to switch to
their alternate mail host it will not be seen as a authorized mail host
at that domain. With load-balancing used to provide multiple exit
points for e-mail from a domain (that may span a large geographical
area), the might not have all their mail hosts listed in their
nameserver. The receiver queries their nameserver, doesn't see an MX
record for the sending mail host, and figures that sending mail host is
not authorized to send from there and aborts the mail session.
You never get back an NDR e-mail telling you about the rejection at
Comcast?
Steve Baker
>Flakey Jakey wrote:
>
>> I am a Comcast subscriber and really have few problems with them. I do,
>> however, have one major problem with receiving email on two accounts.
>>
>> I use NetIdentity netidentity.com) which is part of Domain Direct
>> (domaindirect.com) to forward email to these two accounts. The two
>> email addresses the netidentity forwards have been in use since I was a
>> flash.net subscriber or perhaps before.
>>
>> I've been on Comcast as my ISP for at least 5 or 6 years and have had
>> only minimal problems with them. Lately, however, for aboput the past 6
>> months, I have had one hell of a time getting the email from the
>> netidentity accounts to forward to comcast. Netidentity regularly tells
>> me that comcast is blocking the forwarding. Within a few hours or
>> sometimes days, the blockage is released and the queued email comes
>> through. It doesn't get lost, netidentity just has to hold it until the
>> comcast imposed blockage is removed.
>>
>> When I look at the netidentity (comain direct) atatus pages, I can see
>> that I am not the only comcast customer that is being blocked. WI talk
>> to domaindirect support people (as I have multiple times in the past 6
>> months), they tell me that it is comcast blockiing all emai lcoming from
>> domaindirect (netidentity) machines.
>
Vanguard, when you're trying to explain something, it's not a good
sign that someone who understands the basic issues can't quite figure
out what you're talking about.
>Because Comcast is blocking on the mail server, the same one all those
>customers are using to forward their e-mails. Hell, I can't even use
>'dig' to retrieve A and MX records to see that they have bothered to
>register their mail host(s) in their nameserver (which is often required
>now as an anti-spam measure).
What do you mean? SPF records? MX records?
I'm not seeing a DNS problem, but a DNS problem would account for
the symptoms: email is delayed, not refused with a permanent error.
>netidentity.com's nameserver isn't
>responding. Many ISPs won't accept messages from mail hosts that are
>not listed in that domain's nameserver.
What does that mean? It sounds like you're wrong, but I know that
you understand the basics of email, so I'm thinking that you just
didn't say what you really meant to say.
>I couldn't use Comcast's DNS to
>query their nameserver to do the 'dig'
It's not clear exactly where the DNS problem is, but it could be at
Comcast's end.
>so I used OpenDNS. They also
>could not connect but they returned their cached information.
How could they return cached information if they had been unable to
connect? Returning cached information is what OpenDNS mostly does...
what makes you think that they "could not connect"?
>netidentity.com's nameserver is at ns*.mailbank.com whose domain
>registrant says they are in Reno, Nevada USA and lists the registrant's
>name for mailbank.com as NetIdentity. The 'dig' using OpenDNS returned
>mx.netidentity.com.cust.hostedemail.com as the MX host registered at
>netidentity.com as the authorized mail host there. hostedemail.com is
>another private domain registration through TuCows so NetIdentity is
>hiding their registration data for that domain.
>
>I went to http://www.mxtoolbox.com/blacklists.aspx and entered the IP
>address for their mail host (216.40.42.4) and it wasn't currently listed
>as a spam source. However, that does not preclude a sender using that
>mail host from being classified as a spam source which got that sender
>added to some blacklist. Some customer under their domain might be
>running their own mail host and that's the one getting blacklisted.
That doesn't make any sense. MX servers generally have nothing to do
with sending email. Sending IP addresses get blocked, not those who
might be relaying through the sending IP address.
>Some blacklists are more dynamic than others. For example, SpamCop's
>listing are only for 24 hours unless a spam record gets tickled by
>further detected or reported spam. I don't know what blacklists that
>Comcast uses or if they might use their own.
>
>So, you NEVER got back an NDR (non-delivery report) from either your own
>e-mail provider or from Comcast notifying you of non-delivery? That
>would provide more information than so far divulged to determine the
>cause of the rejection.
>
>You mention a lot of domains but never mentioned which mail server is
>actually attempting to connect to Comcast to deliver your e-mail. You
>mention flash.net but in all the mentions of domains you do not describe
>the relationship between them. For what you've said so far, maybe
>flash.net is your registered domain being webhosted by Domain Direct who
>uses NetIdentity's services to provide disk space and web servers along
>with their e-mail service (i.e., Domain Direct resells NetIdentity's
>services). You definitely have quite the hodgepodge setup.
It's not a hodgepodge setup, that was just a historical reference.
The Vanguard rant. You think Comcast looks at whois records to
decide who they want email from? No way.
>If Comcast is repeatedly re-adding whatever mail host you end up using
>as its exit mail host from DomainDirect.com, NetIdentity.com,
>hostedemail.com, or whatever connects to Comcast's SMTP mail host then
>you can either complain to whomever manages that sending mail host
>regarding their lack of blocking outbound spam or find somewhere else to
>deliver your e-mails, like yet another forwarding service that Comcast
>doesn't regularly blacklist.
Generally good advice.
>It may not even be blacklisting that is the problem. If the nameserver
>at the professed domain for the sending mail host doesn't list that mail
>host then the receiving mail host will see it as an unauthorized mail
>host at that domain.
Huh? Are you talking about SPF? Comcast doesn't pay any attention to
SPF records.
>The receiver might only allow connects from a
>sender that is authorized at the source domain. Many times domains
>screw up when they revert to a secondary or backup mail host in that it
>has not been added to their nameserver, so when they have to switch to
>their alternate mail host it will not be seen as a authorized mail host
>at that domain. With load-balancing used to provide multiple exit
>points for e-mail from a domain (that may span a large geographical
>area), the might not have all their mail hosts listed in their
>nameserver. The receiver queries their nameserver, doesn't see an MX
>record for the sending mail host, and figures that sending mail host is
>not authorized to send from there and aborts the mail session.
Hmm. You mentioned MX hosts, so you're not talking about SPF
records. You're just spouting total nonsense. Meandering nonsense. ;-)
>You never get back an NDR e-mail telling you about the rejection at
>Comcast?
He said:
"Within a few hours or
sometimes days, the blockage is released and the queued email comes
through. It doesn't get lost, netidentity just has to hold it until
the comcast imposed blockage is removed."
--
Steve Baker
Flakey Jakey
Can't find anything about how to handle it in ano of the comcast FAQ's
Comcast forums are next to useless, too many obnoxious responses and no
one seems to know much.
Telephone support and online chat people say I'm spamming.
But it is not just me and my wife, it is all of the Domain Direct
customers. Domain Direct says Comcast is blocking because of spamming
from their machines. Domain Direct says 'not us'. I suspect it really is:
1) Domain Direct may have one or more of their customers flooding but
they seem pretty good at watching for excessive usage.
2) Comcast sees stuff coming from the top level of Domain Direct and
puts it all in one bucket. When the count or rate of transfers exceeds
a Comcast defined limit, they shut the whole thing down. (This seems
the most likely cause).
3) Comcast has some limit set somewhere that they use to block excessive
traffic. They set that limit for all sources to some arbitrary limit
and they don't know how to adjust it for particular sources. Since
Domain Direct is PRIMARILY a forwarding service (you get a domain name
and userid and all your email goes there. They then send it to your
real ISP), they would naturally have a significant amount of traffic
going to Comcast and other ISP's.
An interesting part of this is that, rarely do other ISP's get blocked.
This has been happening almost weekly with Comcast over the past 6
months. Domain Direct is pretty open about noting on their status page
when Comcast is blocking. Over the past 6 months, I think I have only
seen one other (ATT?) ISP that was blocked.
Domain Direct 'upper management' is supposedly involved in some kind of
discussions with Comcast about the problem but I don't really expect
much to come of that.
Domain Direct has a long history, under varoius name in doing this
forwarding. As I said, I really haven't had a problem except for the
past 6 months (that is about 6 months or so after Domain Direct was
bought by Tucows, hmmmm?)
Frosted_Flake
> On Tue, 12 Aug 2008 15:44:21 -0500, VanguardLH <V...@nguard.LH> wrote:
>
>>
>> Working backwards, and when your e-mail scheme is all working, what is
>> the path for inbound e-mails to reach your Comcast e-mail account?
Received: from imta09.emeryville.ca.mail.comcast.net ([76.96.30.93])
by alnrmxc14.comcast.net (alnrmxc14) with ESMTP
id <20080702153527a14005029fe>; Wed, 2 Jul 2008 15:35:27 +0000
X-Originating-IP: [76.96.30.93]
Received: from forward.hostedemail.com ([216.40.42.17])
by IMTA09.emeryville.ca.mail.comcast.net with comcast
id l3bG1Z00S0NDDE0093bLvY; Wed, 02 Jul 2008 15:35:25 +0000
Received: from forward.hostedemail.com (ff-bigip1 [10.5.19.254])
by ofagrave01.hostedemail.com (Postfix) with ESMTP id 5E94C35FC3
for <{{MY COMCAST USERID}}@comcast.net>; Tue, 1 Jul 2008 16:54:56
+0000 (UTC)
Received: from smtpin06.emaildefenseservice.com (smtpin06.a.tucows.com
[10.5.16.6])
by ofarelay01.hostedemail.com (Postfix) with SMTP id E807A106527
for <{{MY COMCAST USERID}}@comcast.net>; Tue, 1 Jul 2008 16:54:55
+0000 (UTC)
Delivered-To: {{MY DOMAIN DIRECT ACCOUNT/NAME}}
X-FDA: 61085076150
X-SpamScore: 5
Received: from QMTA07.emeryville.ca.mail.comcast.net
(qmta07.emeryville.ca.mail.comcast.net [76.96.30.64])
for <{{MY DOMAIN DIRECT ACCOUNT/NAME}}>; Tue, 1 Jul 2008 16:54:54
+0000 (UTC)
Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36])
by QMTA07.emeryville.ca.mail.comcast.net with comcast
id kbLU1Z00S0mlR8UA70SW00; Tue, 01 Jul 2008 16:54:53 +0000
Received: from [192.168.2.2] ([69.254.203.33])
by OMTA11.emeryville.ca.mail.comcast.net with comcast
id kgud1Z00A0jl4jp8Xgujrk; Tue, 01 Jul 2008 16:54:44 +0000
Message-Id: <380496DB-781A-4D9E...@comcast.net>
snip
X-Mailer: Apple Mail (2.924)
X-Spam-Summary: 2,0,0,fb84a69c1e9743da,4145ae2ca5a471eb,{{THE SENDER
NAME/ACCOUNT}},,RULES_HIT:355:379:476:541:564:945:946:962:973:980:983:988:989:1189:1208:1221:1260:1261:1313:1314:1345:1431:1437:1515:1516:1517:1521:1535:1543:1575:1589:1594:1711:1730:1777:1792:2198:2199:2379:2551:2552:2553:2559:2562:2693:2892:2905:3352:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3909:4117:4321:4362:5007:7652:7903:7904:7974:8518:8583:8603:8660,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not
bulk,SPF:,MSBL:none,DNSBL:none
X-Panda: scanned!
X-Forwarded-for: {{MY DOMAIN DIRECT ACCOUNT/NAME}} by Tucows
Ed Mullen
Interesting.
I have one correspondent whose ISP blocks email from 1and1, my host and
email server. It's insane. It's an obscure company and they provide no
way to contact them. My friend finally told me to use a different email
addy (gmail or something) to contact her.
Too many of these ISPs, small and large, are relying on automated tools
to do this blocking. The engineers studied it, the accountants analyzed
the cost-benefit of it, and now there is no human involved in it.
Ultimately? They'll lose my friend as a customer.
--
Ed Mullen
http://edmullen.net
Can you buy anything specific at a general store?
VanguardLH
Since the OP hasn't replied yet to my response, how did you come up with
that conclusion?
>>Because Comcast is blocking on the mail server, the same one all those
>>customers are using to forward their e-mails. Hell, I can't even use
>>'dig' to retrieve A and MX records to see that they have bothered to
>>register their mail host(s) in their nameserver (which is often required
>>now as an anti-spam measure).
>
> What do you mean? SPF records? MX records?
As stated, "retrieve A and MX records". I never mentioned SPF anywhere
in my reply (it is only valid between the two mail hosts' communication
with each other, and the user/client should never use it because bogus
SPF records can be inserted into the headers to mislead users/clients).
>>netidentity.com's nameserver isn't
>>responding. Many ISPs won't accept messages from mail hosts that are
>>not listed in that domain's nameserver.
>
> What does that mean? It sounds like you're wrong, but I know that
> you understand the basics of email, so I'm thinking that you just
> didn't say what you really meant to say.
I only know some of mail systems (and only a little about DNS) based on
having to resolve my own problems regarding e-mail.
When using Comcast's DNS server to initiate the 'dig', it could not
retrieve any records from netidentity's nameserver. I don't know the
cause of that as the error simply said the target nameserver
(netidentity) would not respond. I then changed to using OpenDNS' DNS
server to do the 'dig'. At that time, it also failed to retrieve
records from netidentity's nameserver - but OpenDNS also caches that
info and provided that copy (but I don't how recent it was).
Some receiving mail servers will now query the professed domain for the
sending mail server to see if the sending mail server is listed at that
domain as an authorized mail host. The MX record maps a domain name to
a list of mail exchange servers for that domain, and there are multiple
MX records, one for each authorized mail host at that domain (that the
domain wants to expose externally at their boundary); see
http://en.wikipedia.org/wiki/MX_record.
Some receiving mail servers will also not accept from a mail host if its
domain's nameserver doesn't contain an A record (or is it the PTR
record?) for the sending mail host. They don't like sending mail hosts
that only identify themself by an IP address and not by an IP name; for
examples, see:
http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18784
http://postmaster.info.aol.com/info/rdns.html
They require a reverse DNS on the IP address to get back an IP
[host]name. So there are a couple of anti-spam techniques both of which
require retrieving records from the professed sending mail host's domain
nameserver: is that host listed in an MX record (so it is known to be
authorized by the operator of that domain and/or does that sending mail
host's IP address have a reverse DNS lookup to get its IP name (which
should be the same as that professed domain)?
As I understand it, the MX record was designed to be used in a
forward-looking sense in that the sending mail host gets the MX record
at the receiving domain to figure out to which host to connect to
establish a mail session. After all, you don't specify what mail host
to connect at the destination domain for the recipient and a list or
table of those receiving mail hosts still has to built from some
information that only the receiving domain knows for which hosts it uses
to accept e-mail traffic. However, this can be reversed for anti-spam
purposes (and not related to SMTP itself) to determine if the sending
mail host is also a valid receiving mail host at the sending domain.
Have a read at:
http://www.watchguard.com/support/faqs/fireware/90/multiwan_and_multiple_mx_records.htm
>>I couldn't use Comcast's DNS to
>>query their nameserver to do the 'dig'
>
> It's not clear exactly where the DNS problem is, but it could be at
> Comcast's end.
I've found that some of Comcast's DNS servers won't support 'dig' (to do
all the record retrieves from the targeted nameserver for the specified
domain, if it can be found). For awhile, the nameservers listed in
Comcast's domain registration would work with 'dig' (but no longer as
you get an error about those nameservers not supporting that function).
Comcast's regional DNS servers assigned to me when using DHCP never
worked with 'dig'. I've moved to using OpenDNS' DNS servers a several
months ago and they support 'dig'. From what little I know of 'dig', it
recursively walks through the DNS servers to get to the domain's own
nameserver to get at its records. I don't bother using the command-line
version of dig.exe (http://serghei.net/windows/dig/dig.html) and instead
use the 'dig' function included in SamSpade.
>>so I used OpenDNS. They also
>>could not connect but they returned their cached information.
>
> How could they return cached information if they had been unable to
> connect? Returning cached information is what OpenDNS mostly does...
> what makes you think that they "could not connect"?
Output from 'dig' (using SamSpade):
08/13/08 01:36:59 dig netidentity.com @ 208.67.222.222
Dig netiden...@ns2.mailbank.com (209.130.152.244) ...
failed, couldn't connect to nameserver
Dig netiden...@ns1.mailbank.com (216.10.106.120) ...
failed, couldn't connect to nameserver
Dig netiden...@208.67.222.222 ...
Non-authoritative answer
Recursive queries supported by this server
Query for netidentity.com type=255 class=1
netidentity.com NS (Nameserver) ns1.mailbank.com
netidentity.com NS (Nameserver) ns2.mailbank.com
This is the output now. When I did it before, there was a separator
area that indicated OpenDNS couldn't contact netidentity's nameserver
and that it was showing its own info (which I have to assume was cached
if it couldn't get it from the target nameserver). I don't have that
prior 'dig' output to look at again but do remember that it didn't look
like the above output. There was something "more" that made me think
that OpenDNS had some older info that it was presenting.
> That doesn't make any sense. MX servers generally have nothing to do
> with sending email. Sending IP addresses get blocked, not those who
> might be relaying through the sending IP address.
Explained above how the sending mail host must find out to which
receiving host it must connect, and it finds that out through the MX
record at the recieving domain's nameserver. That is how SMTP works,
not how anti-spam schemes work. The anti-spam schemes turn this around
figuring that if a host isn't listed as an authorized (listed) receiving
mail host then it also isn't an authorized sending mail host at that
domain. SMTP both sends and receives (it is an SMTP mail host at both
ends of the mail session).
No users know what Comcast uses as their criteria for whatever
blacklists they use (and they won't reveal if they compile their own
list or use someone else's, like SpamHaus). Reread that paragraph. It
was pointed at the OP as to whether they want to trust someone that
takes their money but chooses to hide. The last sentence was a jibe,
not a declaration that I know inside information on how Comcast compiles
its blacklist.
>>It may not even be blacklisting that is the problem. If the nameserver
>>at the professed domain for the sending mail host doesn't list that mail
>>host then the receiving mail host will see it as an unauthorized mail
>>host at that domain.
>
> Huh? Are you talking about SPF? Comcast doesn't pay any attention to
> SPF records.
No, I'm back to "the receiving mail host wants an MX record to qualify
the sending host is authorized as a mail host on that domain."
>
>>The receiver might only allow connects from a
>>sender that is authorized at the source domain. Many times domains
>>screw up when they revert to a secondary or backup mail host in that it
>>has not been added to their nameserver, so when they have to switch to
>>their alternate mail host it will not be seen as a authorized mail host
>>at that domain. With load-balancing used to provide multiple exit
>>points for e-mail from a domain (that may span a large geographical
>>area), the might not have all their mail hosts listed in their
>>nameserver. The receiver queries their nameserver, doesn't see an MX
>>record for the sending mail host, and figures that sending mail host is
>>not authorized to send from there and aborts the mail session.
>
> Hmm. You mentioned MX hosts, so you're not talking about SPF
> records. You're just spouting total nonsense. Meandering nonsense. ;-)
Must be all those mail admins are also not making sense when they
discuss that they forgot to include an MX record (and priority) in the
nameserver for their backup mail host when it becomes active because
their primary is offline. Read the article that I presented above from
Watchguard on how the MX record isn't just used for SMTP but also in
anti-spam schemes.
>>You never get back an NDR e-mail telling you about the rejection at
>>Comcast?
>
> He said:
>
> "Within a few hours or
> sometimes days, the blockage is released and the queued email comes
> through. It doesn't get lost, netidentity just has to hold it until
> the comcast imposed blockage is removed."
That could be caused by greylisting and the receiving mail host have
extraordinary blocking intervals between retries, the receiving mail
host being down, unreachable, or too busy, and the sending mail host
doing its duty in retrying to send, or for some other reason that I
might not list. I haven't heard that Comcast employs greylisting. I'd
love to have that as a configurable option in my Comcast e-mail
accounts. The retries to send *should* issue a warning e-mail back to
the sender if the retries extend beyond 1 or 4 hours (I've seen both
intervals) and that would indicate that retries were attempted and will
continue to be attempted, and then an NDR gets sent back if the maximum
number of retries of max time for them has elapsed. I have seen retries
extend out to a day but don't remember any that extended out to "days"
which is an unspecified number and might just be exaggerated by the OP
due to his frustration. I've also seen mail servers that batch up
e-mails. They don't send them all out immediately when the user
transfers a message to their mail host. I've seen mail servers that
batched them up for an hour and, in one case, batched them up to send
every 4 hours, so anything that screwed up that batching could end up
causing excessive intervals between batches. And an internal problem
with the sending mail host doesn't result in any NDRs sent back to the
sender and when the problem finally gets fixed is when that queue of
messages gets processed. A "status page" won't reveal those internal
problems or maintenance even if planned. Most times those status pages
are worthless and you find out about an outage, problem, or maintenance
of YOUR end of the mail (i.e., your e-mail providers servers) until
maybe several days later, if at all should they decide to reveal those
difficulties. What the admins and techs are doing to repair their mail
hosts often never ends up getting the webmaster notified to update that
status page or get an update sent to a script to update that status
data.
VanguardLH
Flakey Jakey (at 71.226.41.78) becomes Frosted_Flake (at 71.226.41.78)
Nymshifters are equated to trolls, spammers, malcontents, and cowards.
Don't nymshift.
Working bottom-up through the Received headers (the order in which they
get prepended to the headers as the message passes through each mail
host):
--- Hop #1:
Received:
from [192.168.2.2] ([69.254.203.33])
by OMTA11.emeryville.ca.mail.comcast.net ...
This is your host (c-69-254-203-33.hsd1.az.comcast.net) connecting to
Comcast to send your e-mail.
--- Hop #2:
Received:
from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36])
by QMTA07.emeryville.ca.mail.comcast.net with comcast
Internal routing within Comcast.
--- Hop #3:
Received:
from QMTA07.emeryville.ca.mail.comcast.net ...
for <{{MY DOMAIN DIRECT ACCOUNT/NAME}}> ...
Odd that the 'by' (receiving) host is missing here. Did you snip it
out? This is the boundary between the externally-facing hosts at
Comcast to the unidentified other end (presumably at DOMAIN DIRECT but
the 'by' clause is missing). Since the 'by' host of a prior Received
header is usually the 'from' host in the next Received header, I'll
guess that DIRECT DOMAIN's boundary mail host is smtpin06.a.tucows.com
from the 'from' clause in the next Received header (where it looks like
TuCows is webhosting the emaildefenseservice.com site or it is a
Tucows-managed mail host).
--- Hop #4:
Received:
from smtpin06.emaildefenseservice.com (smtpin06.a.tucows.com
[10.5.16.6])
by ofarelay01.hostedemail.com ...
for <{{MY COMCAST USERID}}@comcast.net> ...
In the from-clause, the 10.x.x.x address is an IANA-reserved address for
intranet hosts only (i.e., private use only). So already the message
has passed beyond the boundary mail hosts at each of the endpoint
domains, so this one is for internal routing. The inter-domain
interface would've (or should've) been specified in the prior Received
header (and why it looks like the 'by' host got deleted from that
record). This e-mail was received from the Comcast domain and the 'for'
shows it is headed back to the Comcast domain. Either
emaildefenseservice.com and hostedemail.com are managed by Tucows or
they are webhosted sites hiding behind Tucows' private registration
since the domains' registrant is listed as Tucows.
--- Hop #5:
Received:
from forward.hostedemail.com (ff-bigip1 [10.5.19.254])
by ofagrave01.hostedemail.com ...
for <{{MY COMCAST USERID}}@comcast.net> ...
This one is goofy. Its 'from' host should be the 'by' host in the prior
Received header. All of a sudden we get to the 'forward' host with no
Received header showing a link to getting to that host. There is a hop
missing because an internal mail host, probably a relay, did not add a
header to identify that internal hop. Also, its 'by' host should be the
'from' host in the next Received header (but it isn't). That is,
normally the hosts should be:
Received: from <by-host in prior Received header>
by <from-host in next Received header>
It's almost like there is a fork here where the 'forward' host got
reached invisibly and it sends a copy of the message to 'ofagrave01'
(i.e., back into the hostedemail.com domain) and also to Comcast (in the
next Received header). I would've expected something like:
Received:
from ofarelay01.hostedemail.com ...
by forward.hostedemail.com ...
which would match up with the prior Received header and the next
Received header. There is no link from the prior Received header to the
'forward' host, and the 'forward' host sends the message to 2 different
hosts which are on different domains. Maybe a relay within their
network doesn't add a Received header and that's how the 'forward' host
suddenly appeared. Maybe the forwarding is "forward with copy" and the
copy has to get sent back into the domain to keep a copy of it (rather
than just leaving it in the mailbox in which it got deposited already to
forward a copy of it). Can't really tell what happened here. You might
want to get hold of Mike Easter since he's pretty good with these
headers (http://tinyurl.com/5q4r62, then show the Activity list to see
in which groups he posts).
--- Hop #6:
Received:
from forward.hostedemail.com ([216.40.42.17])
by IMTA09.emeryville.ca.mail.comcast.net ...
This is the boundary between the externally-facing SMTP mail hosts at
the endpoint domains. Nothing unexpected here.
--- Hop #7:
Received:
from imta09.emeryville.ca.mail.comcast.net ([76.96.30.93])
by alnrmxc14.comcast.net (alnrmxc14) ...
This is some internal routing within Comcast to reach your mailbox for
your account at Comcast.
Without stating how you sent the e-mail, my guess is that you sent a
test e-mail from your Comcast account to your webhosted domain's e-mail
address which then came back to your Comcast account. All the
non-Comcast domains are either mail hosts managed by Tucows or webhosted
domains hiding behind Tucows private registrations, so I can't who
actually manages those mail hosts. According to IANA requirements, the
registrant must be the one responsible for that domain but registrars
providing private registrations get around that with a loophole by
specifying themself as the registrant. So you could start your
complaints with Tucows because they have overtly declared themself as
the responsible owner (registrant) of those domains. Tucows will
probably attempt to pass off responsibility for the mail servers by
claiming they are managed by the webhost customers - but THEY decided to
list themself as the responsible party for those domains. Sometimes it
doesn't require much pressure to get a registrar to divuge contact info
for whomever used a private registration; i.e., they'll fess up if
pushed (and without requiring subpoenas).
Have you asked Tucows or whomever is your webhost provider to look in
their logs to see WHY their mail sessions with the Comcast SMTP mail
host were rejected or aborted? That "Comcast blocks us" is not a
suitable excuse because it provides no details of what actually happened
during the attempted handshaking and if a mail session started then what
aborted it. Hell, they could have a flaky route between their SMTP mail
hosts and Comcast's SMTP mail host. They simply cannot cannot reach
Comcast's SMTP mail host and have to wait until the unresponsive host in
their route comes back alive or they get a new route, and meanwhile
their outbound queue keeps piling up more e-mails. I have to wonder if
your e-mail provider is even instigating communications with Comcast
when they can't deliver their e-mails to Comcast. What you said they
said sounds like they're just blowing off their customers with a generic
response.
Frosted_Flake
> Frosted_Flake wrote:
>
> Flakey Jakey (at 71.226.41.78) becomes Frosted_Flake (at 71.226.41.78)
> Nymshifters are equated to trolls, spammers, malcontents, and cowards.
> Don't nymshift.
>
I didn't intentionally. I had a bit of a problem with my fat fingers.
Sorry
> --- Hop #3:
> Received:
> from QMTA07.emeryville.ca.mail.comcast.net ...
> for <{{MY DOMAIN DIRECT ACCOUNT/NAME}}> ...
> Odd that the 'by' (receiving) host is missing here. Did you snip it
> out? This is the boundary between the externally-facing hosts at
> Comcast to the unidentified other end (presumably at DOMAIN DIRECT but
> the 'by' clause is missing). Since the 'by' host of a prior Received
> header is usually the 'from' host in the next Received header, I'll
> guess that DIRECT DOMAIN's boundary mail host is smtpin06.a.tucows.com
> from the 'from' clause in the next Received header (where it looks like
> TuCows is webhosting the emaildefenseservice.com site or it is a
> Tucows-managed mail host).
I don't think so but maybe I did do an inadvertent snip, again too much
fat on the fingers.
Actually, this was an email that I received from one of my correspondent
who also happens to be a comcast customer.
I think you may have hit the nail on the head. None of these problems
happened before TUCOWS got involved. Since I have some email
Flakey Jakey
> VanguardLH wrote:
>> Frosted_Flake wrote:
>>
>> Flakey Jakey (at 71.226.41.78) becomes Frosted_Flake (at 71.226.41.78)
>> Nymshifters are equated to trolls, spammers, malcontents, and cowards.
>> Don't nymshift.
>>
>
> I didn't intentionally. I had a bit of a problem with my fat fingers.
> Sorry
>
>
(to be polite) on this setup. Sorry, sorry, sorry
Steve Baker
...
>They require a reverse DNS on the IP address to get back an IP
>[host]name. So there are a couple of anti-spam techniques both of which
>require retrieving records from the professed sending mail host's domain
>nameserver: is that host listed in an MX record (so it is known to be
>authorized by the operator of that domain and/or does that sending mail
>host's IP address have a reverse DNS lookup to get its IP name (which
>should be the same as that professed domain)?
>
>As I understand it, the MX record was designed to be used in a
>forward-looking sense in that the sending mail host gets the MX record
>at the receiving domain to figure out to which host to connect to
>establish a mail session. After all, you don't specify what mail host
>to connect at the destination domain for the recipient and a list or
>table of those receiving mail hosts still has to built from some
>information that only the receiving domain knows for which hosts it uses
>to accept e-mail traffic. However, this can be reversed for anti-spam
>purposes (and not related to SMTP itself) to determine if the sending
>mail host is also a valid receiving mail host at the sending domain.
>Have a read at:
>
>http://www.watchguard.com/support/faqs/fireware/90/multiwan_and_multiple_mx_records.htm
OK, I see where you're going wrong. Yes, it's very common to refuse
email if the connecting IP address doesn't have a PTR (rDNS) record.
That URL says this:
"Because outgoing connections from behind your Firebox can show
different source IP addresses
when your Firebox uses multi-WAN, it is important to make sure that
your DNS records include
MX records for each external IP address that can show as the source
when you send email."
That's kinda confusing; IP addresses don't have MX records. They
mean that one of their MX records should resolve to the sending IP
address. Which brings us to the heart of the matter. MX records are
about receiving email. It's unusual for sending servers to also be the
MX servers, so IT DOESN'T MATTER if the sending IP address has nothing
to do with MX servers. If that was a requirement, most legit email
would be refused. The MX check they're talking about there is a check
on the domain part of sender email addresses; the sending *host* has
nothing to do with it. I kept mentioning SPF because SPF *is* about
checking to see whether the sending host is supposed to be sending
email for the domain part of the sender email address. That is
published via DNS TXT records.
>
>>>I couldn't use Comcast's DNS to
>>>query their nameserver to do the 'dig'
>>
>> It's not clear exactly where the DNS problem is, but it could be at
>> Comcast's end.
>
>I've found that some of Comcast's DNS servers won't support 'dig' (to do
>all the record retrieves from the targeted nameserver for the specified
>domain, if it can be found). For awhile, the nameservers listed in
>Comcast's domain registration would work with 'dig' (but no longer as
>you get an error about those nameservers not supporting that function).
Those servers used to open servers that would accept queries via
TCP. They aren't anymore.
>Comcast's regional DNS servers assigned to me when using DHCP never
>worked with 'dig'.
They only respond to queries made via UDP, and they don't talk to
folks from outside of Comcast.
>I've moved to using OpenDNS' DNS servers a several
>months ago and they support 'dig'. From what little I know of 'dig', it
>recursively walks through the DNS servers to get to the domain's own
>nameserver to get at its records.
Not quite. Dig queries a nameserver, and that nameserver does the
recursion. SSP "dig" has options that mostly do what you describe, but
dig generally refers to the Unix/Linux tool.
>I don't bother using the command-line
>version of dig.exe (http://serghei.net/windows/dig/dig.html) and instead
>use the 'dig' function included in SamSpade.
>
>>>so I used OpenDNS. They also
>>>could not connect but they returned their cached information.
>>
>> How could they return cached information if they had been unable to
>> connect? Returning cached information is what OpenDNS mostly does...
>> what makes you think that they "could not connect"?
>
>Output from 'dig' (using SamSpade):
>
>08/13/08 01:36:59 dig netidentity.com @ 208.67.222.222
>Dig netiden...@ns2.mailbank.com (209.130.152.244) ...
>failed, couldn't connect to nameserver
>Dig netiden...@ns1.mailbank.com (216.10.106.120) ...
>failed, couldn't connect to nameserver
>Dig netiden...@208.67.222.222 ...
>Non-authoritative answer
>Recursive queries supported by this server
> Query for netidentity.com type=255 class=1
> netidentity.com NS (Nameserver) ns1.mailbank.com
> netidentity.com NS (Nameserver) ns2.mailbank.com
SSP isn't a good tool for DNS stuff, it has some bugs and quirks. I
use it all the time, but I often have to work around its issues. One
problem is that, after doing a forward lookup, the reverse lookup on
the IP addresses returned by the forward lookup will always say that
the PTR record is the host name that was originally queried on. It
won't acutally do the reverse lookup. The relevant quirk here is that
SSP uses TCP when it does "dig", and many servers will only respond to
UDP queries. That is the problem here with the ns[12].mailbank.com
servers.
>
>This is the output now. When I did it before, there was a separator
>area that indicated OpenDNS couldn't contact netidentity's nameserver
>and that it was showing its own info (which I have to assume was cached
>if it couldn't get it from the target nameserver). I don't have that
>prior 'dig' output to look at again but do remember that it didn't look
>like the above output. There was something "more" that made me think
>that OpenDNS had some older info that it was presenting.
>
>> That doesn't make any sense. MX servers generally have nothing to do
>> with sending email. Sending IP addresses get blocked, not those who
>> might be relaying through the sending IP address.
>
>Explained above how the sending mail host must find out to which
>receiving host it must connect, and it finds that out through the MX
>record at the recieving domain's nameserver. That is how SMTP works,
>not how anti-spam schemes work. The anti-spam schemes turn this around
>figuring that if a host isn't listed as an authorized (listed) receiving
>mail host then it also isn't an authorized sending mail host at that
>domain.
Again, that is just plain wrong. Only crazy people would refuse
email based on that.
...
--
Steve Baker
NormanM
> Ed Mullen wrote:
>> So, what does Comcast say about their blocking of those accounts? If
>> Netidentity is correct that Comcast is blocking them, you need to
>> contact Comcast to resolve the problem.
> Can't find anything about how to handle it in ano of the comcast FAQ's
Comcast is blocking two specific AT&T mail servers: 'nlpi015.prodigy.net'
and 'nlpi029.prodigy.net'. The bounces include this link:
http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18628
I am waiting for some kind of response from AT&T over this issue.
> Comcast forums are next to useless, too many obnoxious responses and no
> one seems to know much.
The Comcast forums won't be much help with Comcast mail server policies.
> Telephone support and online chat people say I'm spamming.
Easy out.
> But it is not just me and my wife, it is all of the Domain Direct
> customers. Domain Direct says Comcast is blocking because of spamming
> from their machines. Domain Direct says 'not us'. I suspect it really is:
>
> 1) Domain Direct may have one or more of their customers flooding but
> they seem pretty good at watching for excessive usage.
> 2) Comcast sees stuff coming from the top level of Domain Direct and
> puts it all in one bucket.
Comcast does not appear to deal with domains. I send from 'aosake.net', my
mother from another "hobby" domain. Email goes out through (front-end),
'mail.pacbell.net'. Mail is actually relayed from a cluster of servers, with
names in the format of, 'nlpi0xx.prodigy.net'. Email through
'nlpi015.prodigy.net' and 'nlpi029.prodigy.net' bounce. Email through
'nlpi001.prodiy.net' and 'nlpi033.priodigy.net' does not. I have no control
over which ATTIS server will handle the email. All that I can do is complain
to AT&T email admins.
I actually have example of spam sent using hijacked computers and accounts.
Source is a hijacked Comcast computer, used as an originating mailhost.
Spammer used a hijacked ATTIS account to authenticate to one of the ATTIS
SMTP message submission servers (of which my 'mail.pacbell.net' is an
example). The hijacked account is necessary because a User_ID+password
combination is needed for access to the server. The email was one of those
phony "CNN" emails, leading to a malicious site to try and compromise the
reader. The headers:
| Received: from spooler by aosake.net (Mercury/32 v4.61); 9 Aug 2008 15:39:44 -0700
| X-Envelope-To: Local User
| X-Apparently-To: %User_ID%@pacbell.net via 68.142.199.169; Sat, 09 Aug 2008 15:24:28 -0700
| X-YahooFilteredBulk: 69.141.83.216
| X-Originating-IP: [69.141.83.216]
| Authentication-Results: mta136.sbc.mail.mud.yahoo.com from=youngsky.co.kr; domainkeys=neutral (no sig)
| Received: from 69.141.83.216 (EHLO nlpi033.prodigy.net) (207.115.36.62)
| by mta136.sbc.mail.mud.yahoo.com with SMTP; Sat, 09 Aug 2008 15:24:28 -0700
| X-Originating-IP: [69.141.83.216]
| Received: from c-69-141-83-216.hsd1.nj.comcast.net (c-69-141-83-216.hsd1.nj.comcast.net [69.141.83.216])
| by nlpi033.prodigy.net (8.13.8 inb regex/8.13.8) with ESMTP id m79MONDA012706
| for <%User_ID%@pacbell.net>; Sat, 9 Aug 2008 17:24:26 -0500
| Date: Sat, 9 Aug 2008 17:24:26 -0500
| Message-Id: <200808092224....@nlpi033.prodigy.net>
| From: CNN Alerts <rico-e...@youngsky.co.kr>
| Reply-To: rico-e...@youngsky.co.kr
| To: %User_ID%@pacbell.net
| Subject: CNN Alerts: My Custom Alert
| MIME-version: 1.0
| Content-Type: TEXT/HTML; charset=US-ASCII
| X-PMFLAGS: 36192896 0 1 YDSJ78YC.CNM
My understanding of Comcast policies lead me to believe that a sufficient
volume of complaint about email from 'nlpi033.prodigy.net) (207.115.36.62)'
by Comcast user would cause Comcast to block that 'prodigy.net' (ATTIS) mail
server. Of course, Comcast *might* block port 25 outbound for their user at
'c-69-141-83-216.hsd1.nj.comcast.net [69.141.83.216]', if the volume is high
enough. But Comcast users who are port 25 blocked whine and moan about it.
> An interesting part of this is that, rarely do other ISP's get blocked.
Comcast, Embarq, and MSN are all currently blocking AT&T; either
'nlpi015.prodigy.net', or 'nlpi029.prodigy.net'. MSN has blocked Comcast in
the past. And so it goes.
> Domain Direct has a long history, under varoius name in doing this
> forwarding. As I said, I really haven't had a problem except for the
> past 6 months (that is about 6 months or so after Domain Direct was
> bought by Tucows, hmmmm?)
Forwarding is especially tricky. Comcast users have forwarding accounts, and
use them to forward *all* of their email to some non-Comcast email address
to their Comcast email account. This includes the spam to those accounts.
Comcast sees the spam, and doesn't consider the user's desires; the
forwarder gets blocked for doing what they do, at the request of the Comcast
users.
BTW, I have a possible solution to the MSN blocking of 'nlpi015.prodigy.net'
and 'nlpi029.proidigy.net', but it depends upon whether my attempt at
setting up an SPF record on my hobboy domain, and my mother's, flies. My
domain SPF records are designating the IP addresses of the ATTIS
'nlpi0xx.prodigy.net' servers, that I have been able to identify as handling
my outbound email, as "permitted senders" for those domains. That *should*
override any blocking, such as MSN does. However, when I 'dig' on my domain,
I get an ambiguous result, and need to discuss what I am doing wrong with my
domain DNS service.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
VanguardLH
> VanguardLH wrote:
>
>>http://www.watchguard.com/support/faqs/fireware/90/multiwan_and_multiple_mx_records.htm
>
> OK, I see where you're going wrong. Yes, it's very common to refuse
> email if the connecting IP address doesn't have a PTR (rDNS) record.
>
> That URL says this:
>
> "Because outgoing connections from behind your Firebox can show
> different source IP addresses
> when your Firebox uses multi-WAN, it is important to make sure that
> your DNS records include
> MX records for each external IP address that can show as the source
> when you send email."
>
> That's kinda confusing; IP addresses don't have MX records. They
> mean that one of their MX records should resolve to the sending IP
> address.
The MX record provides the name of a valid host on the receiving end.
Once that's obtained, a PTR record is needed to actually know to what
host to connect at that receiving end. If the sending mail host was not
also an MX host, there would be no point in getting the IP address of
any MX host on the sending end.
> Which brings us to the heart of the matter. MX records are
> about receiving email.
Yep, when discussing SMTP, not when discussing anti-spam schemes which
are obviously not part of SMTP.
> It's unusual for sending servers to also be the
> MX servers, so IT DOESN'T MATTER if the sending IP address has nothing
> to do with MX servers. If that was a requirement, most legit email
> would be refused. The MX check they're talking about there is a check
> on the domain part of sender email addresses; the sending *host* has
> nothing to do with it. I kept mentioning SPF because SPF *is* about
> checking to see whether the sending host is supposed to be sending
> email for the domain part of the sender email address. That is
> published via DNS TXT records.
The part of that article that I read was:
-----
Many anti-spam solutions, including those used by most major ISP
networks and web mail providers, such as AOL, MSN, and Yahoo!, use a
reverse MX lookup procedure. There are different variations of the
reverse lookup, but the goals are the same: the receiving server wants
to verify that the email it receives does not come from a spoofed or
forged sending address, and that the sending server is an authorized
mail exchanger for that domain.
To verify that the sending server is an authorized email server, the
receiving email server tries to find an MX record that correlates to the
sender’s domain. If it cannot find one, it assumes that the email is
spam and rejects it.
The domain name that the receiving server looks up can be any of these:
‧ The domain name in the email’s From: header
‧ The domain name in the email’s Reply-To: header
‧ The domain name the sending server uses as the FROM parameter of the
MAIL command. (An SMTP command is different from an email header. The
sending server sends the MAIL FROM: command to tell the receiving sender
who the message is from.)
‧ The domain name returned from a DNS query of the connection’s source
IP address. The receiving server sometimes does a lookup for a PTR
record associated with the IP address. A PTR DNS record is a record that
maps an IP address to a domain name (instead of a normal A record, which
maps a domain name to an IP address).
Before the receiving server continues the transaction, it makes a DNS
query to see if there is a valid MX record for the sender’s domain. If
the domain has no valid DNS MX record, then the sender is not valid and
the receiving server rejects it as a spam source.
-----
To me, it looks like the receiving mail host looks at the return-path
info for the sender's info (From, Reply-To, MAIL command issued by the
sending mail host) to get the professed domain and then asks the sending
mail host's nameserver to see if the MX record from there has a hostname
with the same domain. Well, users are allowed to specify anything in
the From and Reply-To headers and that may not include a domain that
matches the one from where they sent their email. That doesn't make it
spam. It only means the user wants replies going to a different account
(on a different domain) from where they send their email. They send
from one domain but receive on another. For example, to get around
Yahoo's appending the spam signature onto emails sent out through their
webmail interface for freebie accounts, I receive emails on the
yahoo.com to my freebie account but I send using my ISP's SMTP mail host
on comcast.net. In my outbound emails, the From and Reply-To will show
a yahoo.com domain although I'm sending from the comcast.net domain. I
did not see that they prioritize from which return-path header they grab
the professed domain of the sender. Maybe they use the MAIL command
which would have the sending mail host professing its domain name rather
than use the From or Reply-To fields since those are data the user's
e-mail client sends in the DATA command and can usually be anything the
user wants.
Sometimes it can be difficult to understand what is trying to be said.
The last paragraph above seems to indicate that sending domain (as
determined by the sender's return-path data) must have an MX record. No
MX record means rejecting email from that sender. And yet you just
claimed that the sending mail host at a domain need not be the same one
as the receiving mail host at that same domain; i.e., the sending mail
host won't have an MX record (but there is one for the receiving mail
host). If a domain should, say, only send emails then it wouldn't need
an MX record which means this anti-spam scheme would reject all messages
from there. This anti-spam scheme has the assumption that any domain
that sends email MUST also accept email.
If the sending mail host doesn't require an MX record (because it will
be different than the receiving mail host at that same domain), what's
the point of the reverse MX check?
> They only respond to queries made via UDP, and they don't talk to
> folks from outside of Comcast.
That would explain why 'dig' doesn't work sometimes because UDP is
expected instead of TCP.
>>I've moved to using OpenDNS' DNS servers a several
>>months ago and they support 'dig'. From what little I know of 'dig', it
>>recursively walks through the DNS servers to get to the domain's own
>>nameserver to get at its records.
>
> Not quite. Dig queries a nameserver, and that nameserver does the
> recursion. SSP "dig" has options that mostly do what you describe, but
> dig generally refers to the Unix/Linux tool.
I didn't mean that SamSpade's 'dig' did the recursion. That's why, just
with the 'dig' command, you have to specify which nameserver to use
because the queries are requested to that nameserver that then does the
DNS requests from that point. Even in SamSpade I have to specify to
which nameserver it connects to send the request.
> SSP isn't a good tool for DNS stuff, it has some bugs and quirks.
Unfortunately I don't have an alternate 'dig' utility. I really don't
want to install Cygwin to get a command-line version of the utility.
Sometimes deciphering SamSpade's 'dig' output is confusing because of
the quirks. The Windows 2000 Resource Kit that I have doesn't have a
'dig' utility and I don't have access to a Windows 2003 Server to grab
it from there or its install CD. I can find out GUI-based 'dig'
utilities for Windows but, so far, they also use TCP, like
http://www.nscan.org/?index=download. SamSpade has been log dead for
several years (didn't its author die?). Know of a better 'dig' utility
for Windows that is free and really easy to use (and also decipher its
output)?
>>The anti-spam schemes turn this around
>>figuring that if a host isn't listed as an authorized (listed) receiving
>>mail host then it also isn't an authorized sending mail host at that
>>domain.
>
> Again, that is just plain wrong. Only crazy people would refuse
> email based on that.
Yet I keep reading more and more articles talking about using the MX
record from the sending domain to validate their outbound servers.
- http://www.circleid.com/posts/fight_spam_with_the_dns_not_the_cia/
- Depending on how you interpret the Watchguard article, it seems to
indicate that the sending mail host's domain (probably from what it
claims in the MAIL command) is compared against the domain in an MX
record in the sender's nameserver. I don't know why they would be
looking at the From and Reply-To headers since that is user-defined data
at the client end, not at their sending mail host.
- http://www.saas.nsw.edu.au/solutions/dns.html, " How DNS Queries are
used to Validate SMTP Clients" secton, step 5.
It's possible that MX checking was a proposed anti-spam scheme that
never caught on because email providers still want a division between
their outbound and inbound mail hosts and might even have them on
different domains.
I haven't read up much on SPF (and it's been a long since then) but my
recollection was that signatures were involved or trusted sender domain
lists. Well, how does that involve the MX record (which was designed to
be a forward-looking device to find the mail host at the *receiving*
domain)? As I recall, SPF was never intended to identify spam. It was
to qualify the sending mail host (and not actually the sending user).
I'm not sure why SPF-enabled mail hosts even bother inserting the SPF
headers in received e-mails. It's not usable at the recipient's end.
In fact, I've seen spam that inserted bogus SPF headers so the
recipient's thought the source has been qualified using SPF.
I know many e-mail providers are using reverse DNS lookups to reject
inbound mails (as spam sources). Wasn't AOL the first [big] one that
employed this scheme? I remember when a big stink erupted when senders
started complaining that their e-mails were getting rejected by AOL
because of this anti-spam policy change.
Regarding the MX checking (that a *sending* mail host is listed by that
domain's nameserver), it's possible that what I've read so far were
proposals. It doesn't require that an SMTP mail host be both send and
receive (since separate MX records could be used for an outbound mail
host versus an inbound host) but it does require that the outbound mail
host be listed in the sending domain's nameserver. It's listed but that
doesn't mean it is a receive host (my guess is that it would have to be
given the lowest priority to ensure RFC-compliant sending mail hosts
would first use the higher priority MX hosts). I don't personally know
of any but then I didn't personally know what, if any, e-mail providers
had implemented greylisting when I read up on it (and now there are lots
of e-mail providers and aliasing services that include greylisting as a
user-configurable option).
Steve Baker
>Steve Baker wrote:
>
>> VanguardLH wrote:
>>
>>>http://www.watchguard.com/support/faqs/fireware/90/multiwan_and_multiple_mx_records.htm
>>
>> OK, I see where you're going wrong. Yes, it's very common to refuse
>> email if the connecting IP address doesn't have a PTR (rDNS) record.
>>
>> That URL says this:
>>
>> "Because outgoing connections from behind your Firebox can show
>> different source IP addresses
>> when your Firebox uses multi-WAN, it is important to make sure that
>> your DNS records include
>> MX records for each external IP address that can show as the source
>> when you send email."
>>
>> That's kinda confusing; IP addresses don't have MX records. They
>> mean that one of their MX records should resolve to the sending IP
>> address.
>
>The MX record provides the name of a valid host on the receiving end.
>Once that's obtained, a PTR record is needed to actually know to what
>host to connect at that receiving end.
It's the A (address) record that's needed. A PTR record is what you
get when you resolve an IP address to a host name.
>If the sending mail host was not
>also an MX host, there would be no point in getting the IP address of
>any MX host on the sending end.
>
>> Which brings us to the heart of the matter. MX records are
>> about receiving email.
>
>Yep, when discussing SMTP, not when discussing anti-spam schemes which
>are obviously not part of SMTP.
>
>> It's unusual for sending servers to also be the
>> MX servers, so IT DOESN'T MATTER if the sending IP address has nothing
>> to do with MX servers. If that was a requirement, most legit email
>> would be refused. The MX check they're talking about there is a check
>> on the domain part of sender email addresses; the sending *host* has
>> nothing to do with it. I kept mentioning SPF because SPF *is* about
>> checking to see whether the sending host is supposed to be sending
>> email for the domain part of the sender email address. That is
>> published via DNS TXT records.
>
>The part of that article that I read was:
>
>-----
>Many anti-spam solutions, including those used by most major ISP
>networks and web mail providers, such as AOL, MSN, and Yahoo!, use a
>reverse MX lookup procedure.
They're talking about SPF type things, I think. I didn't think AOL
used anything like that, but MSN and Yahoo definitely do... for some
values of "use".
>There are different variations of the
>reverse lookup, but the goals are the same: the receiving server wants
>to verify that the email it receives does not come from a spoofed or
>forged sending address, and that the sending server is an authorized
>mail exchanger for that domain.
That's exactly what SPF does. Note that the "forged sending address"
they're talking about is the sender email address. There's confusion
over what the term "sender" means in different contexts.
>To verify that the sending server is an authorized email server, the
>receiving email server tries to find an MX record that correlates to the
>senderĄŚs domain. If it cannot find one, it assumes that the email is
>spam and rejects it.
That's either confusing or wrong, depending on what they mean by the
"sender's domain". For example, it's perfectly valid for me to use the
Comcast SMTP servers using an email address of mine that isn't
@comcast.net. If I use a bogus email address that doesn't have an MX/A
record, it doesn't say anything about the Comcast SMTP server (but
Comcast wouldn't accept such email from me if the Return Path address
had no MX/A record).
>The domain name that the receiving server looks up can be any of these:
>
>
> ĄE The domain name in the emailĄŚs From: header
>
> ĄE The domain name in the emailĄŚs Reply-To: header
>
> ĄE The domain name the sending server uses as the FROM parameter of the
>MAIL command. (An SMTP command is different from an email header. The
>sending server sends the MAIL FROM: command to tell the receiving sender
>who the message is from.)
>
> ĄE The domain name returned from a DNS query of the connectionĄŚs source
>IP address. The receiving server sometimes does a lookup for a PTR
>record associated with the IP address. A PTR DNS record is a record that
>maps an IP address to a domain name (instead of a normal A record, which
>maps a domain name to an IP address).
That just seems to be about checking to make sure the sending IP
address has a PTR record.
>Before the receiving server continues the transaction, it makes a DNS
>query to see if there is a valid MX record for the senderĄŚs domain. If
>the domain has no valid DNS MX record, then the sender is not valid and
>the receiving server rejects it as a spam source.
The "sender domain" there refers to the domain in an email address.
>-----
>
>To me, it looks like the receiving mail host looks at the return-path
>info for the sender's info (From, Reply-To, MAIL command issued by the
>sending mail host) to get the professed domain and then asks the sending
>mail host's nameserver to see if the MX record from there has a hostname
>with the same domain.
No, it asks the relevant nameserver about MX/A records.
>Well, users are allowed to specify anything in
>the From and Reply-To headers and that may not include a domain that
>matches the one from where they sent their email. That doesn't make it
>spam.
Exactly.
>It only means the user wants replies going to a different account
>(on a different domain) from where they send their email. They send
>from one domain but receive on another. For example, to get around
>Yahoo's appending the spam signature onto emails sent out through their
>webmail interface for freebie accounts, I receive emails on the
>yahoo.com to my freebie account but I send using my ISP's SMTP mail host
>on comcast.net. In my outbound emails, the From and Reply-To will show
>a yahoo.com domain although I'm sending from the comcast.net domain. I
>did not see that they prioritize from which return-path header they grab
>the professed domain of the sender. Maybe they use the MAIL command
>which would have the sending mail host professing its domain name rather
>than use the From or Reply-To
The Return Path (argument of the Mail command) is also user
specified, it's often not about the sending host at all. However, some
outfits, like Gmail, will rewrite the Return Path and make it be an
address that they've authorized.
SPF only looks at the Return Path. The MS version of SPF looks at
the From and maybe Reply To headers lines.
>fields since those are data the user's
>e-mail client sends in the DATA command and can usually be anything the
>user wants.
>
>Sometimes it can be difficult to understand what is trying to be said.
>The last paragraph above seems to indicate that sending domain (as
>determined by the sender's return-path data) must have an MX record. No
>MX record means rejecting email from that sender.
Right.
>And yet you just
>claimed that the sending mail host at a domain need not be the same one
>as the receiving mail host at that same domain; i.e., the sending mail
>host won't have an MX record (but there is one for the receiving mail
>host).
You shouldn't be thinking in terms of hosts, you should be thinking
in terms of domains. Host names seldom have MX records. For example,
one of Comcast's sending hosts is 76.96.30.56, aka
jqmta06.emeryville.ca.mail.comcast.net. There is no MX record for
jqmta06.emeryville.ca.mail.comcast.net.
>If a domain should, say, only send emails then it wouldn't need
>an MX record which means this anti-spam scheme would reject all messages
>from there. This anti-spam scheme has the assumption that any domain
>that sends email MUST also accept email.
Your interpretation of it has that assumption. However, by RFCs,
domains that send email must accept email to at least a role account
or two.
>If the sending mail host doesn't require an MX record (because it will
>be different than the receiving mail host at that same domain), what's
>the point of the reverse MX check?
I think they're talking about schemes like SPF, not actual MX
lookups, that say which servers are authorized to send for which
sender email addresses.
Here is Comcast's TXT (SPF) record, and their MX servers. The MX
servers are contained in the SPF record, but there are many hosts in
the SPF record. Comcast doesn't actually use SPF for anything, or
expect anyone else to, it's just a way for them to publish their
sending hosts should anyone care to whitelist them.
comcast.net. 300 IN TXT "v=spf1
ip4:76.96.28.0/23 ip4:76.96.30.0/24 ip4:76.96.60.0/23
ip4:76.96.62.0/24 ?all"
mx1.comcast.net has address 76.96.62.116
mx2.comcast.net has address 76.96.30.116
The bottom line is that email receivers DO NOT CARE whether or not
the sending host is also an MX server. Almost all largish outfits
segregate the sending and receiving of email.
...
>I didn't mean that SamSpade's 'dig' did the recursion.
It does, though. But "normal" dig doesn't, it just queries one
nameserver.
>That's why, just
>with the 'dig' command, you have to specify which nameserver to use
>because the queries are requested to that nameserver that then does the
>DNS requests from that point. Even in SamSpade I have to specify to
>which nameserver it connects to send the request.
And then SSP has the option to query the authoritative DNS servers
it finds in the original query response.
...
> SamSpade has been log dead for
>several years (didn't its author die?).
No, Steve Atkins is alive and well.
>Know of a better 'dig' utility
>for Windows that is free and really easy to use (and also decipher its
>output)?
There is a utility called Cyberkit which doesn't have the options of
*nix dig, but it's pretty good for basic DNS stuff. Ironically, the
fact that Cyberkit was the only Windoze "toolkit" around at the time
was what prompted Steve to write SSP. I don't like the way output is
formatted, but it does the job. I know there are some web sites that
do a decent job, but I don't have any pointers handy.
...
--
Steve Baker