Jump to content

Stale PTR record as possible source of spam complaints


temmokan

Recommended Posts

Hello,

The story so far: a spam complaint is received, sent through SpamCop, and while studying headers of the original spam message, I notice that although PTR record for spam origin returns a domain name 9say, example.com), the actual A records for example.com do not match the spam origin IP.

That means a false/out-of-date PTR record(s) exists that makes SpamCop decide the domain owner is at fault and their server works as spam source. In reality, IP has nothing to with example.com.

hat could be avoided if the check were made to make sure that both PTR returns a domain name *and* domain has at least one A/AAAA record matching the one reported.

Otherwise, it opens wide possibilities to compromise any legitimate domain: create a false PTR for it, use the IP as spam source and voila - the domain owner will have to prove they aren't spammers.

Is the mentioned A-PTR comparison made currently when analyzing the spam messages?

Thanks.

Link to comment
Share on other sites

There will be exceptions but mostly the SpamCop parser looks at the relevant Regional Internet Registry (for example RIPE) database for an abuse address of the spam "source", usually taken as the IP address stamped in the message headers for the server passing the message to the (first) mail host in the receiving reporter's network. Chain tests for earlier relays and hand-offss are not made for most (too easily forged/spoofed) but it remains a capability of the parser. Originating E-mail addresses are never trusted, those are spoofs in most spam and accordingly they would rarely match with the apparent originating hosts' mail exchangers.

Domain names only come into the picture for website spam links ("spamvertizing") within the spam body, in which case there is a lookup of the A record and then the RIR network whois data.

Link to comment
Share on other sites

Domain names only come into the picture for website spam links ("spamvertizing") within the spam body, in which case there is a lookup of the A record and then the RIR network whois data.

The issue I mentioned relates to 'spamvetizing'.

Looks like no checks were made to make sure that PTR record that reported a reference to a domain name as never tested to be authentic.

The domain for which the spamvertizing complaint was fired at hosting provider, doesn't use the IP, its A zone records do not match the spam origin IP.

I conclude, that if the above is regular SpamCop parser logic, then it has a major flaw allowing to frame any domain as participating in spamvertizing. Here is the setup:

- create a PTR record for anyone's domain

- launch spam delivery from that IP, using the target domain as Reply-To base

Voila. Sooner or later, SpamCop will receive a sample of the spam and file a complaint to hosting provider. Now the domain owner has to prove their innocence. Meanwhile, domain owner's mail sever will be flooded with angry responses and bounces.

No one can prevent people from setting false PTR records. It's too easy to do.

I suggest changing the parser logic when PTR records are used to return a domain name. The simplest check is to retrieve that domain's A records and compare.

I hope you understand that all the domains can be framed in this manner and there're no means to prevent that.

Link to comment
Share on other sites

The issue I mentioned relates to 'spamvetizing'.

Looks like no checks were made to make sure that PTR record that reported a reference to a domain name as never tested to be authentic.

The domain for which the spamvertizing complaint was fired at hosting provider, doesn't use the IP, its A zone records do not match the spam origin IP.

I conclude, that if the above is regular SpamCop parser logic, then it has a major flaw allowing to frame any domain as participating in spamvertizing.

...

I hope you understand that all the domains can be framed in this manner and there're no means to prevent that.

Sorry, I did not understand. I confess I understand very little :blush: (just a SC user) I don't even know that the parser references the PTR record in such cases, certainly not all spam domains have that record (see ysphitnetline.net) yet SC still attempts resolution via the DNS records of the de-obfuscated linked domain and looks to whois.arin.net and subsequent referrals for reporting addresses.

I'm sure the deputies are better equipped to respond in this matter, they are well aware of many difficulties associated with website reporting which is one reason why SC does not have that area of spam fighting as a primary focus and produces no blacklists of spam domains (but yes, does send reports to the apparent host authority - unless they have already declined to accept reports). Why don't you fire off an e-mail outlining your concerns as outined and including details of the spamvertized link in question? One of them should be able to respond to your concerns.

Write to deputies[at]admin.spamcop.net

Link to comment
Share on other sites

...

Why don't you fire off an e-mail outlining your concerns as outined and including details of the spamvertized link in question? One of them should be able to respond to your concerns.

Write to deputies[at]admin.spamcop.net

Thanks for the advice.

In fact, it is not my domain that has been hit with false spamvertizing complaint.

I'll send the advice to the domain owner, to get that report off the database.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...