Text 635, 288 rader
Skriven 2004-09-18 16:45:10 av Rich (1:379/45)
Kommentar till text 634 av Geo. (1:379/45)
Ärende: Re: Spammers faster than the good guys....
==================================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_019F_01C49D9E.DC9396B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The FQDN doesn't need to match, just the domain. You normally would =
expect to get a different FQDN in response to a reverse lookup of a = different
IP.
All of these checks are hacks and unreliable. They are simply =
peoples attempts to try and identify some characteristic that could =
distinguish good email from bad. That is one reason why you find such =
variety in the checks that get performed or whether any are performed. = And
plenty of these are bad. I hear of good mail being bounced because = some ISP
is making an invalid check.
Rich
"Geo." <georger@nls.net> wrote in message news:414ca985@w3.nls.net...
With that kind of a check you would run into the same problem.
MX lookup for Microsoft shows mailc.microsoft.com as one of the mx =
records
nslookup mailc.microsoft.com
Name: mailc.microsoft.com
Addresses: 131.107.3.126, 131.107.3.121
nslookup 131.107.3.126
Name: mail6.microsoft.com
Address: 131.107.3.126
so the forward and reverse lookup of the MX don't match.
Geo. (this is nothing wrong with that setup, it is just a bad test)
"Rich" <@> wrote in message news:414b1241@w3.nls.net...
The reverse DNS check to which I referred is not that the domain of =
the
sending machine matches the domain of the sender. That is known not =
to work
and is why Sender-ID has a richer mechanism. What was described to me =
is that
the forward and reverse of the MX record match and that the match the =
net block
owner or at least I have had email bounce from someone that claimed =
these
checks. Maybe it is someone that doesn't get high volume.
Rich
"Geo." <georger@nls.net> wrote in message =
news:414ab6ef@w3.nls.net...
No they don't, at least most don't.
For example netlink does a MX check but not a PTR check because =
there are
tons
of domains that send mail thru a shared server (any ISP who hosts =
multiple
domains) and that server has only a single PTR record. As such that =
PTR can
match the forward lookup for the server but it can't match every =
domain the
server handles. If you just check the PTR and then do a forward =
lookup to see
if it matches then you gain nothing since pretty much every =
compromised home
machine has matching DNS entries like that so it's worthless. As a =
result the
only thing we bother checking is that an MX exists in order to sort =
of
validate
the FROM address domain isn't total bs.
Don't misunderstand, some people do check the FROM domain against =
the PTR,
but
those servers don't handle any volumes or they would quickly be out =
of
business.
Geo.
"Rich" <@> wrote in message news:414a62ee$1@w3.nls.net...
And the folks that check MX also often perform reverse DNS on the =
sending
IP
to make sure the domain matches.
Rich
"Geo." <georger@nls.net> wrote in message =
news:414a202f@w3.nls.net...
"Rich" <@> wrote in message news:4147b794$1@w3.nls.net...
>> First, I'm still looking for you to provide real world =
examples that
anyone does this along with a description of how it benefits =
them.<<
Nobody does it yet because SPF isn't making the spammers lives any =
tougher
yet.
As far as the technique, all you do is point the MX record for the =
domain
you
are spamming from and that's the IP address the bounces are going =
to go to.
>> As for your claim of no MX or MX pointing to a non-existent =
IP, you
better
explain why that doesn't address the issue you claim that spammers =
have. I
thinnk you are off in never never land. No MX record should be =
faster than
a
valid MX as the NDR is abandoned.<<
That may be true, but no MX record is also a good way to get your =
mail
rejected
since lots of servers verify the sending domain has an MX record =
as part of
their spam filtering.
Geo.
------=_NextPart_000_019F_01C49D9E.DC9396B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.3790.186" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2> The FQDN doesn't need to =
match, just=20
the domain. You normally would expect to get a different FQDN in =
response=20
to a reverse lookup of a different IP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> All of these checks are =
hacks and=20
unreliable. They are simply peoples attempts to try and identify =
some=20
characteristic that could distinguish good email from bad. That is =
one=20
reason why you find such variety in the checks that get performed or = whether
any=20
are performed. And plenty of these are bad. I hear of good =
mail=20
being bounced because some ISP is making an invalid check.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Geo." <<A =
href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote=20
in message <A=20
=
href=3D"news:414ca985@w3.nls.net">news:414ca985@w3.nls.net</A>...</DIV>Wi=
th that=20
kind of a check you would run into the same problem.<BR><BR>MX lookup =
for=20
Microsoft shows mailc.microsoft.com as one of the mx =
records<BR><BR>nslookup=20
mailc.microsoft.com<BR>Name: =20
mailc.microsoft.com<BR>Addresses: 131.107.3.126,=20
131.107.3.121<BR><BR>nslookup 131.107.3.126<BR>Name: =
mail6.microsoft.com<BR>Address: 131.107.3.126<BR><BR>so the =
forward and=20
reverse lookup of the MX don't match.<BR><BR>Geo. (this is nothing =
wrong with=20
that setup, it is just a bad test)<BR><BR>"Rich" <@> wrote in =
message <A=20
=
href=3D"news:414b1241@w3.nls.net">news:414b1241@w3.nls.net</A>...<BR>&nbs=
p; =20
The reverse DNS check to which I referred is not that the domain of=20
the<BR>sending machine matches the domain of the sender. That is =
known=20
not to work<BR>and is why Sender-ID has a richer mechanism. What =
was=20
described to me is that<BR>the forward and reverse of the MX record =
match and=20
that the match the net block<BR>owner or at least I have had email =
bounce from=20
someone that claimed these<BR>checks. Maybe it is someone that =
doesn't=20
get high volume.<BR><BR>Rich<BR><BR> "Geo." <<A=20
href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote in =
message <A=20
=
href=3D"news:414ab6ef@w3.nls.net">news:414ab6ef@w3.nls.net</A>...<BR>&nbs=
p; No=20
they don't, at least most don't.<BR><BR> For example netlink =
does a MX=20
check but not a PTR check because there are<BR>tons<BR> of =
domains that=20
send mail thru a shared server (any ISP who hosts multiple<BR> =
domains)=20
and that server has only a single PTR record. As such that PTR =
can<BR> =20
match the forward lookup for the server but it can't match every =
domain=20
the<BR> server handles. If you just check the PTR and then do a =
forward=20
lookup to see<BR> if it matches then you gain nothing since =
pretty much=20
every compromised home<BR> machine has matching DNS entries like =
that so=20
it's worthless. As a result the<BR> only thing we bother =
checking is=20
that an MX exists in order to sort of<BR>validate<BR> the FROM =
address=20
domain isn't total bs.<BR><BR> Don't misunderstand, some people =
do check=20
the FROM domain against the PTR,<BR>but<BR> those servers don't =
handle=20
any volumes or they would quickly be out of<BR> =
business.<BR><BR> =20
Geo.<BR><BR> "Rich" <@> wrote in message <A=20
=
href=3D"news:414a62ee$1@w3.nls.net">news:414a62ee$1@w3.nls.net</A>...<BR>=
=20
And the folks that check MX also often perform reverse DNS on the=20
sending<BR>IP<BR> to make sure the domain matches.<BR><BR> =
Rich<BR><BR> "Geo." <<A=20
href=3D"mailto:georger@nls.net">georger@nls.net</A>> wrote in =
message <A=20
=
href=3D"news:414a202f@w3.nls.net">news:414a202f@w3.nls.net</A>...<BR>&nbs=
p; =20
"Rich" <@> wrote in message <A=20
=
href=3D"news:4147b794$1@w3.nls.net">news:4147b794$1@w3.nls.net</A>...<BR>=
=20
>> First, I'm still looking for you to provide real =
world=20
examples that<BR> anyone does this along with a =
description=20
of how it benefits them.<<<BR><BR> Nobody does =
it yet=20
because SPF isn't making the spammers lives any tougher<BR> =20
yet.<BR> As far as the technique, all you do is =
point the MX=20
record for the domain<BR>you<BR> are spamming from =
and=20
that's the IP address the bounces are going to go=20
to.<BR><BR> >> As for your claim =
of no MX=20
or MX pointing to a non-existent IP, you<BR> =20
better<BR> explain why that doesn't address the =
issue you=20
claim that spammers have. I<BR> thinnk you are =
off in=20
never never land. No MX record should be faster=20
than<BR>a<BR> valid MX as the NDR is=20
abandoned.<<<BR><BR> That may be true, but no =
MX=20
record is also a good way to get your mail<BR> =20
rejected<BR> since lots of servers verify the =
sending domain=20
has an MX record as part of<BR> their spam=20
filtering.<BR><BR> =20
Geo.<BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_019F_01C49D9E.DC9396B0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|