Showing posts with label ipv4. Show all posts
Showing posts with label ipv4. Show all posts

August 30, 2013

SPEWS Memorial Day

Every August 30th the APEWS.org website changes it's home page to show the following;

 **************************************

Today our website and our mail-servers are not available, because it is 30 August - SPEWS MEMORIAL DAY

Our beloved SPEWS operator got hit by a truck and died 30 August 2006. One of his dreams was to make the world a spam free place.
As long as spam exists we therefore recommend all of you to shutdown all mail-servers at every 30. August for 24 hours.
Be creative to make today a black day for all spammers and spam supporters and a day without mail and spam.
It is just one day in the year so it will not hurt you nor your company, but it will set a widely visible sign if enough people do so.
Our blacklists are online, but we will not display reasons for listings nor do any removals by today.
We will be back by tomorrow. APEWS - Anonymous Postmasters Early Warning System.

 **************************************

The man behind the former blacklist known as SPEWS was visionary in that he recognized that playing with dynamic listings was mot a solution, just prolonging the problem and in fact permitting both spammers and anti-spammers to continue to profit from the problem at the expenses of the general public internet users.

Instead he designed a fixed listing system that prevented the internet service providers (ISP) from recycling their IP space for profit, listing them as having a bad reputation. The SPEWS blacklist database was known to be fairly aggressive with the ISPs that ignored the spam problem whilst making money from it.

From what we know, the founder of SPEWS was not only an experienced driver but had additional training possibly as a driving instructor. He also liked to drive one of the safest cars manufactured yet, despite this, whilst driving his usual cross-country route between home and office, a truck appeared and there was a crash that left the SPEWS founder dead. That was August 30th 2006. Was there foul play?

We think that if the SPEWS founder was still alive today, he would be pleased with the progress that APEWS.org has made using his ideology and advancing it further to cover all ISPs and IPv4 space.

July 18, 2013

L2.APEWS.ORG False Positive #21

We're publishing this one for the record, the newsletter was found in the junk folder by the user but was in fact subscribed to. The IP address has already been de-listed so this is just for information;

Tue 2013-07-16 05:49:33: [6716:1620] Accepting SMTP connection from [63.121.28.41]
Tue 2013-07-16 05:49:33: [6716:1620] Looking up PTR record for 63.121.28.41 (41.28.121.63.IN-ADDR.ARPA)
Tue 2013-07-16 05:49:34: [6716:1620] D=41.28.121.63.IN-ADDR.ARPA TTL=(59) PTR=[unicamailman301-q1.sb.monster.com]
Tue 2013-07-16 05:49:34: [6716:1620] Gathering A-records for PTR hosts
Tue 2013-07-16 05:49:34: [6716:1620] D=unicamailman301-q1.sb.monster.com TTL=(60) A=[63.121.28.41]
Tue 2013-07-16 05:49:34: [6716:1620] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Tue, 16 Jul 2013 05:49:34 -0500
Tue 2013-07-16 05:49:34: [6716:1620] <-- HELO unicamailman301-q1.sb.monster.com
Tue 2013-07-16 05:49:34: [6716:1620] Performing reverse lookup on unicamailman301-q1.sb.monster.com (looking for 63.121.28.41)
Tue 2013-07-16 05:49:34: [6716:1620] D=unicamailman301-q1.sb.monster.com TTL=(60) A=[63.121.28.41]
Tue 2013-07-16 05:49:34: [6716:1620] --> 250 xxx.xxx.xxx Hello unicamailman301-q1.sb.monster.com, pleased to meet you
Tue 2013-07-16 05:49:34: [6716:1620] <-- MAIL FROM:<smas.30-230433_448550_3@e0.monster.com>
Tue 2013-07-16 05:49:34: [6716:1620] Performing reverse lookup on e0.monster.com (looking for 63.121.28.41)
Tue 2013-07-16 05:49:34: [6716:1620] D=e0.monster.com TTL=(10) A=[63.112.169.1]
Tue 2013-07-16 05:49:35: [6716:1620] P=020 D=e0.monster.com TTL=(10) MX=[mailsorter.sb.monster.com] {63.121.30.235}
Tue 2013-07-16 05:49:35: [6716:1620] P=020 D=e0.monster.com TTL=(10) MX=[mailsorter.be.tmpw.net] {208.71.195.235}
Tue 2013-07-16 05:49:35: [6716:1620] Spam Blocker A-record resolution of [41.28.121.63.L2.APEWS.ORG] in progress (DNS Server: 192.168.1.2)...
Tue 2013-07-16 05:49:35: [6716:1620] Spam Blocker D=41.28.121.63.L2.APEWS.ORG TTL=(35) A=[127.0.0.2]
Tue 2013-07-16 05:49:35: [6716:1620] L2.APEWS.ORG LISTED
Tue 2013-07-16 05:49:35: [6716:1620] Message will be accepted and X-RBL-Warning: header will be inserted.
Tue 2013-07-16 05:49:35: [6716:1620] --> 250 <smas.30-230433_4 @ .monster.com>, Sender ok
Tue 2013-07-16 05:49:35: [6716:1620] <-- RCPT TO:<xxx@xxx.xxx>
Tue 2013-07-16 05:49:35: [6716:1620] --> 250 <xxx@xxx.xxx>, Recipient ok
Tue 2013-07-16 05:49:35: [6716:1620] <-- DATA
Tue 2013-07-16 05:49:35: [6716:1620] --> 354 Enter mail, end with <CRLF>.<CRLF>
Tue 2013-07-16 05:49:36: [6716:1620] --> 250 Ok, message saved <Message-ID: emsg.826.7140f20 @ unica7emsg201.be.monster.com>
Tue 2013-07-16 05:49:36: [6716:1620] <-- QUIT
Tue 2013-07-16 05:49:36: [6716:1620] --> 221 See ya in cyberspace
Tue 2013-07-16 05:49:36: [6716:1620] SMTP session successful, 13598 bytes transferred.
Tue 2013-07-16 05:49:36: [6716:1620] Shuffling message(s) into proper queue(s)
Tue 2013-07-16 05:49:36: [6716:1620] Message received from unicamailman301-q1.sb.monster.com [63.121.28.41] <smas.30-230433_448550_3 @ .monster.com> with SMTP for <xxx@xxx.xxx> [Size 0] {j:\localq\1150000318214.msg}

September 20, 2012

Still no False Positives

There simply haven't been any false positives to write about. A lot of people are requesting delisting and removal from Apews.org here but they are all email senders whereas this blog is aimed at receivers of email that use the apews.org data for filtering or blocking.

Anyone wanting a removal would do better to publish the email header from a receiver as we have done.

These days it's all about reputation and permission, even new allocations to existing ISPs that have a bad rep can expect to remain listed. Folks have had enough of snowshoe spamming out of newly acquired IP blocks.

IPv4 address space is nearly all allocated and most of it has been assessed by the apews.org team to great effect. Consistently trapping 95% or more of spam sent with less then 0.5% false positives is a great statistic so there can't be much wrong with the apews.org data. We encourage email receivers to publish errors here, prove the error with the full email headers, munge them for privacy if you want to. That way there is a public record of the error in your view, shame apews.org into fixing that error.

We can see that soon there will be no more IPv4 addresses for spammers to pollute, old existing allocations will have to be cleaned up in order to regain a good rep or stay listed. No residential IP address space needs to send email so outbound connections to port TCP 25 should be disallowed at the ISP firewall and it's so easy to do.

Right now there needs to be a 2 tier tariff for IP addresses, the price for apews.org listed IP address space should be dirt cheap to rent or even free since there is ad revenue from the http traffic. That is the usual business model, give free access with commercials which cover the costs incurred. ISPs are running all their user traffic through http proxy servers for ad tracking etc, try blocking their http server addresses at your firewall and you will lose your internet connection.

Clean IP address space that never gets listed by blacklists is obviously run professionally and volume email senders do so with the permission of the recipient. Their IP address space should command a premium in value and they deserve to earn more out of their email sending services e.g. providing smart hosts for clients. They won't take dirty email databases though :-) If you're really serious about inboxing then pay for a service from one of these guys.

Nice to see more email servers using the l2.apews.org for blocking as published on NANAE usenet newsgroup recently. Spam is no longer problem. We've had a lot of extra spare time for server maintenance and monitoring the whitelists, user complaints have stopped and the techs are up to date. In our server logs we've seen subscriptions to newsletter being honored, not bounced by using the apews dataset, what more can I say. Once we see the subscription process followed by an acceptance email we whitelist that enews server.

June 14, 2012

Some analysis of Apews data

This has taken a while since there is a lot of it! By comparing our own records with listings that exist in the Apews dataset we have been able to conclude the following;

Single IP addresses that have made a direct connection to our servers in order to send spam email have also been found in C-1, C-2, C-12, C-35C-52, C-53, C-66, C-67, C-73 and C-630.

Mostly /24 listings can mostly be found in C-3, C-11, C-13, C-21, C-36, C-41, C-130, C-1375 and C-1402. These /24 generally include the above single IP addresses suggesting that they are maybe escalations.

Single IP addresses that have done port scanning, SSH probes, attempted PHP or SQL injection, password guessing, hosting landing pages that contain virus, trojan etc have only been found in C-16 and C-86.

CIDR that contain residential customers, typically have no reverse DNS and generic host names (as noted in some records by Apews) have been found in C-22, C-1010 and C-1403. These are often referred to as dynamic since they can be large DHCP pools too. These CIDR would not be RFC compliant for the sending of emails.

Other CIDR, usually larger than /24, can be found in C-14, C-15, C-17, C-18, C-20, C-79, C-258 and C-813.

May 16, 2012

DNS Blacklist Editor

I came across a useful tool (freeware) at http://www.jhsoft.com/ which is for editing a DNS blacklist. By using RSYNC we got a copy of the APEWS dataset and opened it up using the above tool, great. For some people it might be easier to edit APEWS data for their own purposes in order to reduce false positives or blacklist more IPv4 than APEWS currently covers. There are reports of L2.APEWS.ORG dataset catching between 95% and 99% of all spam so that shouldn't take much editing to tailor it for any one system.

Some DNS blacklist databases separate the type of blacklisting by using a code number in the dns record of the listed IP address e.g. an email spam sender IP might get a DNSBL response of 127.0.0.3, a spam relay IP could show as 127.0.0.4 but a trojan hosting website IP come back with 127.0.0.5. Those different 127.0.0.* IP addresses can be used for filtering email or other traffic by e.g. using the "3" and "4" for an inbound email stream but the "5" for outbound HTTP traffic i.e. preventing users getting to the trojan host. However it looks like APEWS dataset returns just one reply to queries "L2.APEWS.ORG TTL=(35) A=[127.0.0.2]".

Looking through the listings and reviewing the comments that used to be written in the earlier records, we can see some groups of "Cases" that may be useful to some people if C number can be obtained. It should even be possible to extract the relevant data to build smaller datasets specific to a need. The groups of Cases and their text descriptors etc will be published shortly.

March 16, 2012

Over 1 month without any FP

As you can see, the last false positive that we found was on Feb 9 and nothing since. We are the only ones to have published email headers in support of those false positives and each one has been delisted by the APEWS.org Administrators. The folks you have seen posting removal requests here are people that believe that their IP addresses should not be listed. We have seen that most, but not all, have been delisted.

The SPEWS listing model was to use whole CIDR blocks in order to pressure the ISP. It involved listing the entire block without regard for individual IP addresses and therefore there was collateral damage which was not favored by many. In order for that method to work it requires that users tolerate the collateral damage until such time as the ISP cleaned up the CIDR. That method was flawed because users, network Administrators etc, would rather tolerate spam than collateral damage.

After analysing the APEWS.org data over a period of time we can see that they are no longer following the same model as SPEWS. A few years ago when they first became a replacement for SPEWS, it could have been said that their method was very close if not the same. However, the fact that false positives have reduced dramatically and having probed the listed CIDR, APEWS.org seem to be cutting holes in CIDR for trusted senders and accordingly reducing collateral damage leaving a binary reputation index.

February 10, 2012

L2.APEWS.ORG False Positive #12

This is another from the travel and tourism newsletters, not sure yet if the listing is tied to the recent "infomercials". We will check the listing, and delisting if it occurs, in due course. The email header follows;

Thur 2012-02-09 16:47:29: [60:170] Accepting SMTP connection from [98.158.230.106]
Thur 2012-02-09 16:47:29: [60:170] Looking up PTR record for 98.158.230.106 (106.230.158.98.IN-ADDR.ARPA)
Thur 2012-02-09 16:47:30: [60:170] D=106.230.158.98.IN-ADDR.ARPA TTL=(59) PTR=[business-travelupdate.com]
Thur 2012-02-09 16:47:30: [60:170] Gathering A-records for PTR hosts
Thur 2012-02-09 16:47:30: [60:170] D=business-travelupdate.com TTL=(1440) A=[98.158.230.106]
Thur 2012-02-09 16:47:30: [60:170] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Thur, 09 Feb 2012 16:47:30 -0500
Thur 2012-02-09 16:47:30: [60:170] <-- EHLO business-travelupdate.com
Thur 2012-02-09 16:47:30: [60:170] Performing reverse lookup on business-travelupdate.com (looking for 98.158.230.106)
Thur 2012-02-09 16:47:30: [60:170] D=business-travelupdate.com TTL=(1440) A=[98.158.230.106]
Thur 2012-02-09 16:47:30: [60:170] --> 250-xxx.xxx.xxx Hello business-travelupdate.com, pleased to meet you
Thur 2012-02-09 16:47:30: [60:170] --> 250-ETRN
Thur 2012-02-09 16:47:30: [60:170] --> 250-AUTH=LOGIN
Thur 2012-02-09 16:47:30: [60:170] --> 250-AUTH LOGIN CRAM-MD5
Thur 2012-02-09 16:47:30: [60:170] --> 250-8BITMIME
Thur 2012-02-09 16:47:30: [60:170] --> 250 SIZE 0
Thur 2012-02-09 16:47:31: [60:170] <-- MAIL FROM:
Thur 2012-02-09 16:47:31: [60:170] Performing reverse lookup on business-travelupdate.com (looking for 98.158.230.106)
Thur 2012-02-09 16:47:31: [60:170] D=business-travelupdate.com TTL=(1439) A=[98.158.230.106]
Thur 2012-02-09 16:47:31: [60:170] Spam Blocker A-record resolution of [106.230.158.98.L2.APEWS.ORG] in progress (DNS Server: 192.168.1.2)...
Thur 2012-02-09 16:47:31: [60:170] Spam Blocker D=106.230.158.98.L2.APEWS.ORG TTL=(35) A=[127.0.0.2]
Thur 2012-02-09 16:47:31: [60:170] L2.APEWS.ORG LISTED
Thur 2012-02-09 16:47:31: [60:170] Message will be accepted and X-RBL-Warning: header will be inserted.
Thur 2012-02-09 16:47:31: [60:170] --> 250 , Sender ok
Thur 2012-02-09 16:47:31: [60:170] <-- RCPT TO:
Thur 2012-02-09 16:47:31: [60:170] --> 250 , Recipient ok
Thur 2012-02-09 16:47:31: [60:170] <-- DATA
Thur 2012-02-09 16:47:31: [60:170] --> 354 Enter mail, end with .
Thur 2012-02-09 16:47:31: [60:170] --> 250 Ok, message saved
Thur 2012-02-09 16:47:31: [60:170] <-- QUIT
Thur 2012-02-09 16:47:31: [60:170] --> 221 See ya in cyberspace
Thur 2012-02-09 16:47:31: [60:170] SMTP session successful, 1453 bytes transferred.
Thur 2012-02-09 16:47:31: [60:170] Shuffling message(s) into proper queue(s)
Thur 2012-02-09 16:47:31: [60:170] Message received from business-travelupdate.com [98.158.230.106] with SMTP for [Size 1419] {j:\localq\500019.msg}

You may see fluctuations in your statistics which could be due to the rotation between IP addresses that some newsletter senders do. Where one IP address is listed and another is not, the newsletter will alternate between the spam folder and the inbox unless you have the IP address in your whitelist and/or a filter to move mis-placed emails.

January 28, 2012

L2.APEWS.ORG False Positive #11

First one this month so far, not bad going. This is another of the sending servers for the travel industry, some of our users found this in their spam folder, incorrectly. It must have been recently listed, I haven't checked as yet what the listing says but as far as we are concerned here, the IP is a trusted source. Here is the email header;

Fri 2012-01-27 16:33:25: [6810:112] Accepting SMTP connection from [205.201.136.59]
Fri 2012-01-27 16:33:25: [6810:112] Looking up PTR record for 205.201.136.59 (59.136.201.205.IN-ADDR.ARPA)
Fri 2012-01-27 16:33:25: [6810:112] D=59.136.201.205.in-addr.arpa TTL=(1440) PTR=[mail59.us4.mandrillapp.com]
Fri 2012-01-27 16:33:25: [6810:112] Gathering A-records for PTR hosts
Fri 2012-01-27 16:33:25: [6810:112] D=mail59.us4.mandrillapp.com TTL=(1440) A=[205.201.136.59]
Fri 2012-01-27 16:33:25: [6810:112] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Fri, 27 Jan 2012 16:33:25 -0500
Fri 2012-01-27 16:33:25: [6810:112] <-- EHLO mail59.us4.mandrillapp.com
Fri 2012-01-27 16:33:25: [6810:112] Performing reverse lookup on mail59.us4.mandrillapp.com (looking for 205.201.136.59)
Fri 2012-01-27 16:33:26: [6810:112] D=mail59.us4.mandrillapp.com TTL=(1440) A=[205.201.136.59]
Fri 2012-01-27 16:33:26: [6810:112] --> 250-xxx.xxx.xxx Hello mail59.us4.mandrillapp.com, pleased to meet you
Fri 2012-01-27 16:33:26: [6810:112] --> 250-ETRN
Fri 2012-01-27 16:33:26: [6810:112] --> 250-AUTH=LOGIN
Fri 2012-01-27 16:33:26: [6810:112] --> 250-AUTH LOGIN CRAM-MD5
Fri 2012-01-27 16:33:26: [6810:112] --> 250-8BITMIME
Fri 2012-01-27 16:33:26: [6810:112] --> 250 SIZE 0
Fri 2012-01-27 16:33:26: [6810:112] <-- MAIL FROM: BODY=8BITMIME
Fri 2012-01-27 16:33:26: [6810:112] Performing reverse lookup on mail59.us4.mandrillapp.com (looking for 205.201.136.59)
Fri 2012-01-27 16:33:26: [6810:112] D=mail59.us4.mandrillapp.com TTL=(1439) A=[205.201.136.59]
Fri 2012-01-27 16:33:26: [6810:112] Spam Blocker A-record resolution of [59.136.201.205.L2.APEWS.ORG] in progress (DNS Server: 192.168.1.2)...
Fri 2012-01-27 16:33:26: [6810:112] Spam Blocker D=59.136.201.205.L2.APEWS.ORG TTL=(35) A=[127.0.0.2]
Fri 2012-01-27 16:33:26: [6810:112] L2.APEWS.ORG LISTED
Fri 2012-01-27 16:33:26: [6810:112] Message will be accepted and X-RBL-Warning: header will be inserted.
Fri 2012-01-27 16:33:26: [6810:112] --> 250 , Sender ok
Fri 2012-01-27 16:33:26: [6810:112] <-- RCPT TO:
Fri 2012-01-27 16:33:26: [6810:112] --> 250 , Recipient ok
Fri 2012-01-27 16:33:26: [6810:112] <-- DATA
Fri 2012-01-27 16:33:26: [6810:112] --> 354 Enter mail, end with .
Fri 2012-01-27 16:33:27: [6810:112] --> 250 Ok, message saved
Fri 2012-01-27 16:33:27: [6810:112] <-- QUIT
Fri 2012-01-27 16:33:27: [6810:112] --> 221 See ya in cyberspace
Fri 2012-01-27 16:33:27: [6810:112] SMTP session successful, 30303 bytes transferred.
Fri 2012-01-27 16:33:27: [6810:112] Shuffling message(s) into proper queue(s)
Fri 2012-01-27 16:33:27: [6810:112] Message received from mail59.us4.mandrillapp.com [205.201.136.59] with SMTP for [Size 32292] {j:\localq\0005140404.msg}

We will check this and report back in due course.

December 25, 2011

L2.APEWS.ORG False Positive #10

Just over a week since the last one, found this which is the tenth in as many weeks, not bad. We know that the email sent by the server was solicited as it was a response to a web purchase, i.e. server generated receipt;

Sat 2011-12-24 06:53:43: [916:2344] Accepting SMTP connection from [83.223.106.9]
Sat 2011-12-24 06:53:43: [916:2344] Looking up PTR record for 83.223.106.9 (9.106.223.83.IN-ADDR.ARPA)
Sat 2011-12-24 06:53:44: [916:2344] D=9.106.223.83.IN-ADDR.ARPA TTL=(1440) PTR=[fusion.bpweb.net]
Sat 2011-12-24 06:53:44: [916:2344] Gathering A-records for PTR hosts
Sat 2011-12-24 06:53:44: [916:2344] D=fusion.bpweb.net TTL=(120) A=[83.223.106.9]
Sat 2011-12-24 06:53:44: [916:2344] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Sun, 25 Dec 2011 06:53:44 -0500
Sat 2011-12-24 06:53:44: [916:2344] <-- EHLO fusion.bpweb.net
Sat 2011-12-24 06:53:44: [916:2344] Performing reverse lookup on fusion.bpweb.net (looking for 83.223.106.9)
Sat 2011-12-24 06:53:44: [916:2344] D=fusion.bpweb.net TTL=(120) A=[83.223.106.9]
Sat 2011-12-24 06:53:44: [916:2344] --> 250-xxx.xxx.xxx Hello fusion.bpweb.net, pleased to meet you
Sat 2011-12-24 06:53:44: [916:2344] --> 250-ETRN
Sat 2011-12-24 06:53:44: [916:2344] --> 250-AUTH=LOGIN
Sat 2011-12-24 06:53:44: [916:2344] --> 250-AUTH LOGIN CRAM-MD5
Sat 2011-12-24 06:53:44: [916:2344] --> 250-8BITMIME
Sat 2011-12-24 06:53:44: [916:2344] --> 250 SIZE 0
Sat 2011-12-24 06:53:45: [916:2344] <-- MAIL From: SIZE=112236
Sat 2011-12-24 06:53:45: [916:2344] Performing reverse lookup on londonmagicstore.co.uk (looking for 83.223.106.9)
Sat 2011-12-24 06:53:45: [916:2344] D=londonmagicstore.co.uk TTL=(119) A=[87.117.239.236]
Sat 2011-12-24 06:53:46: [916:2344] P=050 D=londonmagicstore.co.uk TTL=(120) MX=[aspmx3.googlemail.com] {74.125.127.27}
Sat 2011-12-24 06:53:46: [916:2344] P=040 D=londonmagicstore.co.uk TTL=(120) MX=[aspmx2.googlemail.com] {74.125.43.27}
Sat 2011-12-24 06:53:46: [916:2344] P=030 D=londonmagicstore.co.uk TTL=(120) MX=[alt2.aspmx.l.google.com]
Sat 2011-12-24 06:53:46: [916:2344] P=020 D=londonmagicstore.co.uk TTL=(120) MX=[alt1.aspmx.l.google.com]
Sat 2011-12-24 06:53:46: [916:2344] P=010 D=londonmagicstore.co.uk TTL=(120) MX=[aspmx.l.google.com]
Sat 2011-12-24 06:53:46: [916:2344] D=alt2.aspmx.l.google.com TTL=(4) A=[74.125.65.26]
Sat 2011-12-24 06:53:46: [916:2344] D=alt1.aspmx.l.google.com TTL=(4) A=[209.85.225.26]
Sat 2011-12-24 06:53:46: [916:2344] D=aspmx.l.google.com TTL=(4) A=[74.125.127.26]
Sat 2011-12-24 06:53:46: [916:2344] Spam Blocker A-record resolution of [9.106.223.83.L2.APEWS.ORG] in progress (DNS Server: 192.168.1.2)...
Sat 2011-12-24 06:53:46: [916:2344] Spam Blocker D=9.106.223.83.L2.APEWS.ORG TTL=(35) A=[127.0.0.2]
Sat 2011-12-24 06:53:46: [916:2344] L2.APEWS.ORG LISTED
Sat 2011-12-24 06:53:46: [916:2344] Message will be accepted and X-RBL-Warning: header will be inserted.
Sat 2011-12-24 06:53:46: [916:2344] --> 250 , Sender ok
Sat 2011-12-24 06:53:46: [916:2344] <-- RCPT To:
Sat 2011-12-24 06:53:46: [916:2344] --> 250 , Recipient ok
Sat 2011-12-24 06:53:47: [916:2344] <-- DATA
Sat 2011-12-24 06:53:47: [916:2344] --> 354 Enter mail, end with .
Sat 2011-12-24 06:53:49: [916:2344] --> 250 Ok, message saved
Sat 2011-12-24 06:53:49: [916:2344] <-- QUIT
Sat 2011-12-24 06:53:49: [916:2344] --> 221 See ya in cyberspace
Sat 2011-12-24 06:53:49: [916:2344] SMTP session successful, 113812 bytes transferred.
Sat 2011-12-24 06:53:49: [916:2344] Shuffling message(s) into proper queue(s)
Sat 2011-12-24 06:53:49: [916:2344] Message received from fusion.bpweb.net [83.223.106.9] with SMTP for [Size 113801] {j:\localq\md0000000.msg}

As before, we will report back if this gets de-listed.

December 24, 2011

Comparison of some DNSBL results

No false positives to report this week, great because email was up to nearly double with all the Xmas communications including contacts so nice that it went smoothly. Use the spare time to put some usage statistics together;

DNSBL

%

Errors

l2.apews.org

95

0.5%

b.barracudacentral.org

94

* uceprotect.net 1,2 & 3

91

<0.2%

zen.spamhaus.org

91

<0.1%

ip.v4bl.org

68

cbl.abuseat.org

68

<0.1%

spam.dnsbl.sorbs.net

65

dnsbl-2.uceprotect.net

63

<0.1%

dnsbl-3.uceprotect.net

63

<0.2%

hostkarma.junkemailfilter.com

62

bl.tiopan.com

61

dnsbl-1.uceprotect.net

51

<0.1%

bl.mailspike.net

45

ix.dnsbl.manitu.net

44

1.5

truncate.gbudb.net

43

bl.spameatingmonkey.net

38

blackholes.five-ten-sg.com

37

bl.spamcop.net

31

<0.1%

psbl.surriel.com

18

<0.1%

db.upbl.info

14

<0.1%

dnsbl.imps.de

8

no-more-funn.moensted.dk

7

<0.1%

bl.spamcannibal.org

3

spam.spamrats.com

2

<0.1%

* does not exist as a single dnsbl, use 3 lists


That accords with our findings too, very respectable error rates before the use of a whitelist. Only Barracuda's system comes close and they require a free registration before you can access their data. You can use a combined result from all 3 lists at UCEProtect.net to achieve similar results though they do have lower error rates.

There are websites that offer a one-stop lookup service, like dnsbl.info, where you can input an IP address and see which blacklists have it listed. In their case, dnsbl.info test 80+ blacklists but do not include l2.apews.org which seems odd when you see the results above. Yet they show the results from other blacklists with more than double the error rate, odd that.

December 19, 2011

Antihosts.exe trojan

Ended up having to fix a client computer over the weekend, Windows 7 with a failed Messenger and Windows Live problems. The trojan had replaced the "hosts" file and replaced it with this version;

191.164.12.1 zuleica
191.162.91.2 tarantula
19.251.32.13 ariranha
112.158.12.22 leandrino
132.168.7.42 zecurlano
121.91.41.151 cotidiano

121.15.12.137 www.banespa.com.br # GbPluguin
121.15.12.137 banespa.com.br # GbPluguin
121.15.12.137 www.santander.com.br # GbPluguin
121.15.12.137 santander.com.br # GbPluguin
121.15.12.137 caixa.com.br # GbPluguin
121.15.12.137 www.cef.gov.br # GbPluguin
121.15.12.137 cef.gov.br # GbPluguin
121.15.12.137 www.cef.com.br # GbPluguin
121.15.12.137 www.caixa.gov.br # GbPluguin
121.15.12.137 caixa.gov.br # GbPluguin
121.15.12.137 www.caixa.com.br # GbPluguin
209.94.172.28 live.com # GbPluguin
209.94.172.28 www.live.com # GbPluguin
209.94.172.28 www.msn.com # GbPluguin
121.15.12.137 cef.com.br # GbPluguin
121.15.12.137 internetbanking.caixa.gov.br # GbPluguin
121.15.12.137 internetbanking.caixa.com.br # GbPluguin
121.15.12.137 internetbanking.cef.gov.br # GbPluguin
121.15.12.137 internetbanking.cef.com.br # GbPluguin
121.15.12.137 www.e-gold.com.br # GbPluguin
121.15.12.137 e-gold.com.br # GbPluguin
121.15.12.137 www.e-gold.com # GbPluguin
121.15.12.137 e-gold.com # GbPluguin
121.15.12.137 www.bradescoprime.com.br # GbPluguin
121.15.12.137 www.cetelem.com.br # GbPluguin
121.15.12.137 cetelem.com.br # GbPluguin
121.15.12.137 www.cartaoaura.com.br # GbPluguin
209.94.172.28 msn.com # GbPluguin
209.94.172.28 www.msn.com.br # GbPluguin
209.94.172.28 login.live.com # GbPluguin
121.15.12.137 cartaoaura.com.br # GbPluguin
121.15.12.137 bradescoprime.com.br # GbPluguin
121.15.12.137 www.itaupersonnalite.com.br # GbPluguin
121.15.12.137 itaupersonnalite.com.br # GbPluguin
121.15.12.137 americanexpress.com.br # GbPluguin
121.15.12.137 www.sicredi.com.br # GbPluguin
121.15.12.137 sicredi.com.br # GbPluguin
121.15.12.137 portal.sicredi.com.br # GbPluguin
121.15.12.137 www.realsecureweb.com.br # GbPluguin
121.15.12.137 realsecureweb.com.br # GbPluguin
209.94.172.28 www.hotmail.com # GbPluguin
209.94.172.28 hotmail.com # GbPluguin
121.15.12.137 www.americanexpress.com.br # GbPluguin
121.15.12.137 www.americanexpress.com # GbPluguin
121.15.12.137 www.real.com.br # GbPluguin
121.15.12.137 www.bancoreal.com.br # GbPluguin
121.15.12.137 real.com.br # GbPluguin
121.15.12.137 bancoreal.com.br # GbPluguin
209.94.172.28 www.hotmail.com.br # GbPluguin
209.94.172.28 hotmail.com.br # GbPluguin
121.15.12.137 itau.com.br # GbPluguin
121.15.12.137 www.itau.com # GbPluguin
121.15.12.137 itau.com # GbPluguin
121.15.12.137 imagem.caixa.gov.br # GbPluguin
121.15.12.137 imagem.caixa.com.br # GbPluguin
121.15.12.137 imagem.cef.gov.br # GbPluguin
121.15.12.137 imagem.cef.com.br # GbPluguin
121.15.12.137 www.bradesco.com.br # GbPluguin
121.15.12.137 bradesco.com.br # GbPluguin
121.15.12.137 www.bradesco.com # GbPluguin
121.15.12.137 bradesco.com # GbPluguin
121.15.12.137 www.itau.com.br # GbPluguin
121.15.12.137 www.realsecureweb.com.br # GbPluguin
121.15.12.137 santanderempresarial.com.br # GbPluguin
121.15.12.137 www.santanderempresarial.com.br # GbPluguin
121.15.12.137 santanderempresarial.com # GbPluguin
121.15.12.137 www.santanderempresarial.com # GbPluguin
121.15.12.137 www.citibank.com.br # GbPluguin
121.15.12.137 citibank.com.br # GbPluguin
121.15.12.137 www.citibank.com # GbPluguin
121.15.12.137 citibank.com # GbPluguin

32.19.12.1 ezekien.lorena
22.93.11.98 marcos.gladiador
11.12.44.1 zumbi.palmares
81.55.12.4 arthur.erculando

Interesting that some USA Department Of Defense IP addresses are referred to as is a Ford Motor Company one too. The others are in South Korea, France, Australia and China. The trojan is capturing user names and passwords for the above mentioned banks etc.

The infection arrived in a spam email from a known-to-the-user Hotmail email address, probably a compromised account, with a link to a video about pedofilia. Clicking the link caused the trojan to install and make various changes including the above hosts file replacement.

Spammers ignore 550 command

Having written about the effectiveness for blocking, we have a spammer that is still trying to send emails to the same email address, on a different server and after a failed previous attempt where a 550 no suvh user was given;

Sat 2011-12-17 05:43:06: [468:256] Accepting SMTP connection from [67.159.33.100]
Sat 2011-12-17 05:43:06: [468:256] Looking up PTR record for 67.159.33.100 (100.33.159.67.IN-ADDR.ARPA)
Sat 2011-12-17 05:43:21: [468:256] The name server reports that it is having technical problems.
Sat 2011-12-17 05:43:21: [468:256] --> 220 xxx1.xxx.xxx ESMTP MDaemon 6.7.9; Sat, 17 Dec 2011 04:43:21 -0500
Sat 2011-12-17 05:43:21: [468:256] <-- EHLO super.jbcapacitacionempresarial.com
Sat 2011-12-17 05:43:21: [468:256] Performing reverse lookup on super.jbcapacitacionempresarial.com (looking for 67.159.33.100)
Sat 2011-12-17 05:43:22: [468:256] D=super.jbcapacitacionempresarial.com TTL=(240) A=[67.159.33.100]
Sat 2011-12-17 05:43:22: [468:256] --> 250-xxx1.xxx.xxx Hello super.jbcapacitacionempresarial.com, pleased to meet you
Sat 2011-12-17 05:43:22: [468:256] --> 250-ETRN
Sat 2011-12-17 05:43:22: [468:256] --> 250-AUTH=LOGIN
Sat 2011-12-17 05:43:22: [468:256] --> 250-AUTH LOGIN CRAM-MD5
Sat 2011-12-17 05:43:22: [468:256] --> 250-8BITMIME
Sat 2011-12-17 05:43:22: [468:256] --> 250 SIZE 0
Sat 2011-12-17 05:43:22: [468:256] <-- MAIL FROM: SIZE=48915
Sat 2011-12-17 05:43:22: [468:256] Performing reverse lookup on jbcapacitacionempresarial.com (looking for 67.159.33.100)
Sat 2011-12-17 05:43:22: [468:256] D=jbcapacitacionempresarial.com TTL=(240) A=[67.159.33.101]
Sat 2011-12-17 05:43:22: [468:256] P=010 D=jbcapacitacionempresarial.com TTL=(240) MX=[mail.jbcapacitacionempresarial.com] {67.159.33.101}
Sat 2011-12-17 05:43:22: [468:256] Spam Blocker A-record resolution of [100.33.159.67.L2.APEWS.ORG] in progress (DNS Server: 192.168.1.3)...
Sat 2011-12-17 05:43:22: [468:256] Spam Blocker D=100.33.159.67.L2.APEWS.ORG TTL=(35) A=[127.0.0.2]
Sat 2011-12-17 05:43:22: [468:256] L2.APEWS.ORG LISTED
Sat 2011-12-17 05:43:22: [468:256] --> 250 , Sender ok
Sat 2011-12-17 05:43:22: [468:256] <-- RCPT TO:
Sat 2011-12-17 05:43:22: [468:256] 'Recipient unknown' given to divert future spam
Sat 2011-12-17 05:43:22: [468:256] --> 550 , Recipient unknown
Sat 2011-12-17 05:43:23: [468:256] <-- QUIT
Sat 2011-12-17 05:43:23: [468:256] --> 221 See ya in cyberspace
Sat 2011-12-17 05:43:23: [468:256] SMTP session successful, 154 bytes transferred.

December 13, 2011

L2.APEWS.ORG False Positive #9

For those that are receiving the newsletters from the folks doing the dolphin watch documentary etc, Ocean Preservation Society, this latest false positive would have been serious. OPS have used CreateSend.com for their newsletter and the subscriber user on our network found it in the spam folder. Shame, lets hope that like with the previous ones, putting it here gets the server IP delisted;

Sat 2011-12-10 15:07:33: [968:7309] Accepting SMTP connection from [184.106.86.136]
Sat 2011-12-10 15:07:33: [968:7309] Looking up PTR record for 184.106.86.136 (136.86.106.184.IN-ADDR.ARPA)
Sat 2011-12-10 15:07:33: [968:7309] D=136.86.106.184.IN-ADDR.ARPA TTL=(5) PTR=[mr136.createsend.com]
Sat 2011-12-10 15:07:33: [968:7309] Gathering A-records for PTR hosts
Sat 2011-12-10 15:07:33: [968:7309] D=mr136.createsend.com TTL=(120) A=[184.106.86.136]
Sat 2011-12-10 15:07:33: [968:7309] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Sat, 10 Dec 2011 15:07:33 -0500
Sat 2011-12-10 15:07:33: [968:7309] <-- EHLO mr136.createsend.com
Sat 2011-12-10 15:07:33: [968:7309] Performing reverse lookup on mr136.createsend.com (looking for 184.106.86.136)
Sat 2011-12-10 15:07:33: [968:7309] D=mr136.createsend.com TTL=(119) A=[184.106.86.136]
Sat 2011-12-10 15:07:33: [968:7309] --> 250-xxx.xxx.xxx Hello mr136.createsend.com, pleased to meet you
Sat 2011-12-10 15:07:33: [968:7309] --> 250-ETRN
Sat 2011-12-10 15:07:33: [968:7309] --> 250-AUTH=LOGIN
Sat 2011-12-10 15:07:33: [968:7309] --> 250-AUTH LOGIN CRAM-MD5
Sat 2011-12-10 15:07:33: [968:7309] --> 250-8BITMIME
Sat 2011-12-10 15:07:33: [968:7309] --> 250 SIZE 0
Sat 2011-12-10 15:07:33: [968:7309] <-- MAIL FROM: BODY=8BITMIME
Sat 2011-12-10 15:07:33: [968:7309] Performing reverse lookup on createsend3.com (looking for 184.106.86.136)
Sat 2011-12-10 15:07:33: [968:7309] D=createsend3.com TTL=(720) A=[27.126.145.32]
Sat 2011-12-10 15:07:33: [968:7309] P=010 D=createsend3.com TTL=(240) MX=[mx1.createsend3.com] {27.126.144.2}
Sat 2011-12-10 15:07:33: [968:7309] Spam Blocker A-record resolution of [136.86.106.184.l2.apews.org] in progress (DNS Server: 192.168.1.2)...
Sat 2011-12-10 15:07:33: [968:7309] Spam Blocker D=136.86.106.184.l2.apews.org TTL=(35) A=[127.0.0.2]
Sat 2011-12-10 15:07:33: [968:7309] APEWS listed, 99.7% certain it is spam
Sat 2011-12-10 15:07:33: [968:7309] Message will be accepted and X-RBL-Warning: header will be inserted.
Sat 2011-12-10 15:07:33: [968:7309] --> 250 , Sender ok
Sat 2011-12-10 15:07:33: [968:7309] <-- RCPT TO:
Sat 2011-12-10 15:07:33: [968:7309] --> 250 , Recipient ok
Sat 2011-12-10 15:07:33: [968:7309] <-- DATA
Sat 2011-12-10 15:07:33: [968:7309] --> 354 Enter mail, end with .
Sat 2011-12-10 15:07:33: [968:7309] --> 250 Ok, message saved
Sat 2011-12-10 15:07:33: [968:7309] <-- QUIT
Sat 2011-12-10 15:07:33: [968:7309] --> 221 See ya in cyberspace
Sat 2011-12-10 15:07:33: [968:7309] SMTP session successful, 26599 bytes transferred.
Sat 2011-12-10 15:07:33: [968:7309] Shuffling message(s) into proper queue(s)
Sat 2011-12-10 15:07:33: [968:7309] Message received from mr136.createsend.com [184.106.86.136] with SMTP for [Size 26584] {j:\localq\md00000000.msg}

December 10, 2011

Whois utility SamSpade

Do you often get IP addresses connecting to your email server and you wonder who the **** is that? The answer is that there is a "Whois" of that information, and for Windows users there is a small well-written program that is very helpful. A visit to SamSpage.org shows "back soon" but the program can still be found for download at;

http://majorgeeks.com/Sam_Spade_d594.html

At just over a Mb it certainly isn't bloated with anything! Once installed it can be opened to reveal a simpe gray window. Put the unknown IP address in the top left box, for this example we will use the spammer just referred to, at 67.159.33.100;

The main registers for IP address ranges are;
ARIN, North American continent
RIPE, European continent and Middle East
LACNIC, Central and South America
APNIC, Asia, Pacific, Far East and Oceana
AFRINIC, Africa

Top center of SamSpade you will see a choice box, select whois.arin.net and then look to the left, down a little you will see an icon for "whois". Click on that and you get the following in your SamSpade window;

NetRange: 67.159.0.0 - 67.159.63.255
CIDR: 67.159.0.0/18
OriginAS:
NetName: FDCSERVERS
NetHandle: NET-67-159-0-0-1
Parent: NET-67-0-0-0-0
NetType: Direct Allocation
RegDate: 2004-10-12
Updated: 2006-12-27

OrgName: FDCservers.net
OrgId: FDCSE
Address: 141 w jackson blvd.
Address: suite #1135
City: Chicago
StateProv: IL
PostalCode: 60604
Country: US
RegDate: 2003-05-20
Updated: 2011-03-28

In our experience FDCServers do not have a good reputation and quite often have their IP addresses listed in the top 100 spam senders at any one time. Probably not too caring about the spam problem.

Another test that you can perform is from the top toolbar, the button called "Basics". Click on that and second one down on the list is NSLOOKUP, a test for finding the DNS name recorded for the IP address or domain name. For 67.159.33.100 we get the following result;

"nslookup 67.159.33.100
No reverse DNS (WSANO_DATA)"

Very impressive, there isn't one. FDCServers have an IP address pumping out emails with no reverse DNS set. The spammer therefore can set the HELO/EHLO server name to what ever he likes and change it whenever he likes. FDC should write the server name in their DNS and setup the PTR record so that it accords with the A record, therefore permitting real-time reverse DNS (rDNS) tests to succeed. You will note that our email server timed out trying to get that IP address DNS record. Failing to do so is open to abuse as we have seen, yet it is so easy to do, it literally takes 5 minutes to edit the DNS and only needs doing once.

Email servers can send emails for and on behalf of numerous domain names and this does not affect the name of the server in DNS, it's reverse DNS record or the HELO/EHLO used.

To get another opinion about IP addresses, networks, network providerss and server hosting businesses, try the following;

http://www.senderbase.org/

Over on the right of the home page you will see a box for "reputation lookup", insert 67.159.33.100 and click the button underneath. The window shows results for the IP address and associated email senders of the same domain name and IP addresses (in this case 67.159.33.0/24). Note the results;

67.159.33.33 is shown as "neutral" written in black text
67.159.33.100 is shown as "neutral" written in black text
67.159.33.101 is shown as "good" written in green text but
67.159.33.100 is shown as "poor" written in red text

Now change the address block to be /18 as the Whois tells us, FDCServers have an IP address block of that size, click "Go";

At the time of writing there are nearly 400 detected email senders from that /18 IP block and there is a lot of red! This second opinion of FDC agrees with our own experience.

Top center of the SenderBase.org web page is a button called "Top Senders", choose "Top Spam Senders" to see a recent report and the same old names.

L2.APEWS.ORG for blocking works great

We've seen a lot of comments on the internet, especially in Usenet net-abuse newsgroups, that Apews.org has no users, false positives are huge and that it is unfit for outright blocking. Alterior motives? Who are these people and why aren't they in here filling up the pages with their tons of test results?

We have been showing all the false positives that we receive on some commercial email servers that receive global email flows. The average FP rate is going to be about one, yes one, email per week! None of them were critical, more inconvenient than anything and in a couple of cases, they were possible FP only that were actually correct in identifying spam.

Are email server Administrators so lazy or incapable that they can't sort out one email a week for a user? And why can't they run a whitelist, I mean, no sane email Administrator would run an email server without one, right?

Here is evidence of a spammer having delivery denied, and you are going to ask how do I know it was spam if delivery was denied? Well, we have setup secondary and tertiary MX servers operating the exact same configuration as the primary servers but with blocking in place, not insert an X-Header for listed IP addresses of senders. The spammer delivered a copy of the same spam to an alternate server and was blocked from delivering on another server, so in that way we were able to see and check the spam to confirm.

Sat 2011-12-10 4:29:07: [1234:787] Accepting SMTP connection from [67.159.33.100]
Sat 2011-12-10 4:29:07: [1234:787] Looking up PTR record for 67.159.33.100 (100.33.159.67.IN-ADDR.ARPA)
Sat 2011-12-10 4:29:07: [1234:787] 3 second wait for DNS response exceeded
Sat 2011-12-10 4:29:07: [1234:787] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Sat, 10 Dec 2011 4:29:07 -0200
Sat 2011-12-10 4:29:07: [1234:787] <-- EHLO super.jbcapacitacionempresarial.com
Sat 2011-12-10 4:29:07: [1234:787] Performing reverse lookup on super.jbcapacitacionempresarial.com (looking for 67.159.33.100)
Sat 2011-12-10 4:29:07: [1234:787] D=super.jbcapacitacionempresarial.com TTL=(240) A=[67.159.33.100]
Sat 2011-12-10 4:29:07: [1234:787] --> 250-xxx.xxx.xxx Hello super.jbcapacitacionempresarial.com, pleased to meet you
Sat 2011-12-10 4:29:07: [1234:787] --> 250-ETRN
Sat 2011-12-10 4:29:07: [1234:787] --> 250-AUTH=LOGIN
Sat 2011-12-10 4:29:07: [1234:787] --> 250-AUTH LOGIN CRAM-MD5
Sat 2011-12-10 4:29:07: [1234:787] --> 250-8BITMIME
Sat 2011-12-10 4:29:07: [1234:787] --> 250 SIZE 0
Sat 2011-12-10 4:29:07: [1234:787] <-- MAIL FROM: SIZE=38288
Sat 2011-12-10 4:29:07: [1234:787] Performing reverse lookup on jbcapacitacionempresarial.com (looking for 67.159.33.100)
Sat 2011-12-10 4:29:07: [1234:787] D=jbcapacitacionempresarial.com TTL=(240) A=[67.159.33.101]
Sat 2011-12-10 4:29:07: [1234:787] P=010 D=jbcapacitacionempresarial.com TTL=(240) MX=[mail.jbcapacitacionempresarial.com] {67.159.33.101}
Sat 2011-12-10 4:29:07: [1234:787] Spam Blocker A-record resolution of [100.33.159.67.l2.apews.org] in progress (DNS Server: 192.168.1.1)...
Sat 2011-12-10 4:29:07: [1234:787] Spam Blocker D=100.33.159.67.l2.apews.org TTL=(35) A=[127.0.0.2]
Sat 2011-12-10 4:29:07: [1234:787] APEWS.ORG listed, 99.7% certain it is spam
Sat 2011-12-10 4:29:07: [1234:787] --> 250 , Sender ok
Sat 2011-12-10 4:29:07: [1234:787] <-- RCPT TO:
Sat 2011-12-10 4:29:07: [1234:787] 'Recipient unknown' given to divert future spam
Sat 2011-12-10 4:29:07: [1234:787] --> 550 , Recipient unknown
Sat 2011-12-10 4:29:07: [1234:787] <-- QUIT
Sat 2011-12-10 4:29:07: [1234:787] --> 221 See ya in cyberspace
Sat 2011-12-10 4:29:07: [1234:787] SMTP session successful, 154 bytes transferred.

The spammer was given a "550" user unknown reply and that should get the email address removed from the sender's database however, these days 550 get ignored and spammers keep trying to deliver to all email servers that they can get access to.

Email servers that send solicited emails do so by checking their cache or public DNS to find where to deliver an email. They try the first MX listed and only try the second or third if delivery was not possible and the retry period exhausted depending on the configuration chosen by the email Administrator of that server. Outbound email servers are typically not listed in DNS as MX i.e. senders and so even though they listen on TCP port 25, they should never receive emails.

Even domain delivery receipts and recipient display or read receipts use the same MX servers in the order of priority MX1, MX2, MX3 etc as configured in DNS by the Administrator for each domain name. Spammers ignore that and just send to all and any servers listening on TCP port 25. L2.Apews.org is therefore excellent for use in blocking and denying delivery on such servers if not other MX servers depending on the ability of the email Administrator.

Look again at the false positives that we have listed here, had we been blocking from day 1 then each of these would not have been allowed delivery into the network. See anything mission critical there? With a decent whitelist those FP would have been even fewer or zero. Why pay for a spam solution? Surely anyone making money out of spam solutions is part of the problem, they wouldn't want to give up their income. Needless to say, good email Administrators are worth their weight in gold, better to pay them than pay for anti-spam services or "solutions".

L2.APEWS.ORG False Positive #8

This one refers back to L2.APEWS.ORG False Positive #4, if you recall the MTV newsletter was found by our user in his spam folder. Having published that here and checking the IP address a day or two later, it was found to be delisted, so then why is another MTV newsletter again in the spam folder? Well, the MTV newsletter didn't come from the same IP address which means that Apews.org had more than one IP address listed in the previous listing. Here is the false positive;

Thu 2011-12-08 08:10:27: [1112:6566] Accepting SMTP connection from [129.228.5.20]
Thu 2011-12-08 08:10:27: [1112:6566] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Thu, 08 Dec 2011 08:10:27 -0500
Thu 2011-12-08 08:10:27: [1112:6566] <-- EHLO mtv-newsletter1.mms.mtv.com
Thu 2011-12-08 08:10:27: [1112:6566] --> 250-xxx.xxx.xxx Hello mtv-newsletter1.mms.mtv.com, pleased to meet you
Thu 2011-12-08 08:10:27: [1112:6566] --> 250-ETRN
Thu 2011-12-08 08:10:27: [1112:6566] --> 250-AUTH=LOGIN
Thu 2011-12-08 08:10:27: [1112:6566] --> 250-AUTH LOGIN CRAM-MD5
Thu 2011-12-08 08:10:27: [1112:6566] --> 250-8BITMIME
Thu 2011-12-08 08:10:27: [1112:6566] --> 250 SIZE 0
Thu 2011-12-08 08:10:27: [1112:6566] <-- MAIL FROM:
Thu 2011-12-08 08:10:27: [1112:6566] Spam Blocker A-record resolution of [20.5.228.129.l2.apews.org] in progress (DNS Server: 192.168.1.2)...
Thu 2011-12-08 08:10:27: [1112:6566] Spam Blocker D=20.5.228.129.l2.apews.org TTL=(35) A=[127.0.0.2]
Thu 2011-12-08 08:10:27: [1112:6566] APEWS listed, 99.7% certain it is spam
Thu 2011-12-08 08:10:27: [1112:6566] Message will be accepted and X-RBL-Warning: header will be inserted.
Thu 2011-12-08 08:10:27: [1112:6566] --> 250 , Sender ok
Thu 2011-12-08 08:10:27: [1112:6566] <-- RCPT TO:
Thu 2011-12-08 08:10:27: [1112:6566] --> 250 , Recipient ok
Thu 2011-12-08 08:10:27: [1112:6566] <-- DATA
Thu 2011-12-08 08:10:27: [1112:6566] --> 354 Enter mail, end with .
Thu 2011-12-08 08:10:28: [1112:6566] --> 250 Ok, message saved
Thu 2011-12-08 08:10:28: [1112:6566] <-- QUIT
Thu 2011-12-08 08:10:28: [1112:6566] --> 221 See ya in cyberspace
Thu 2011-12-08 08:10:28: [1112:6566] SMTP session successful, 20649 bytes transferred.
Thu 2011-12-08 08:10:28: [1112:6566] Shuffling message(s) into proper queue(s)
Thu 2011-12-08 08:10:28: [1112:6566] Message received from mtv-newsletter1.mms.mtv.com [129.228.5.20] with SMTP for [Size 20634] {j:\localq\md00000.msg}

After some further checking, it turns out that MTV have 4 consecutive IP addresses in Viacom address space, namely 129.228.5.20-129.228.5.23 so you might want to whitelist those. We have never had any problem with the MTV servers, check e.g. whitelist DNSWL.org for other trustworthy IP addresses in the same neighborhood as those.

At the time of writing this, none of those 4 IP addresses are showing as listed so it seems that Apews.org have corrected the MTV newsletter issue.

December 8, 2011

L2.APEWS.ORG False Positive #7

This is another example of a possible false positive because it will depend on your client base and email flow.

Wed 2011-12-07 03:59:15: [1144:6063] Accepting SMTP connection from [61.135.132.132]
Wed 2011-12-07 03:59:15: [1144:6063] Looking up PTR record for 61.135.132.132 (132.132.135.61.IN-ADDR.ARPA)
Wed 2011-12-07 03:59:17: [1144:6063] D=132.132.135.61.IN-ADDR.ARPA TTL=(59) PTR=[websmtp.sohu.com]
Wed 2011-12-07 03:59:17: [1144:6063] Gathering A-records for PTR hosts
Wed 2011-12-07 03:59:18: [1144:6063] D=websmtp.sohu.com TTL=(10) A=[61.135.132.204]
Wed 2011-12-07 03:59:18: [1144:6063] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Wed, 07 Dec 2011 03:59:18 -0500
Wed 2011-12-07 03:59:18: [1144:6063] <-- EHLO websmtp.sohu.com
Wed 2011-12-07 03:59:18: [1144:6063] Performing reverse lookup on websmtp.sohu.com (looking for 61.135.132.132)
Wed 2011-12-07 03:59:18: [1144:6063] D=websmtp.sohu.com TTL=(9) A=[61.135.132.204]
Wed 2011-12-07 03:59:18: [1144:6063] --> 250-xxx.xxx.xxx Hello websmtp.sohu.com (may be forged), pleased to meet you
Wed 2011-12-07 03:59:18: [1144:6063] --> 250-ETRN
Wed 2011-12-07 03:59:18: [1144:6063] --> 250-AUTH=LOGIN
Wed 2011-12-07 03:59:18: [1144:6063] --> 250-AUTH LOGIN CRAM-MD5
Wed 2011-12-07 03:59:18: [1144:6063] --> 250-8BITMIME
Wed 2011-12-07 03:59:18: [1144:6063] --> 250 SIZE 0
Wed 2011-12-07 03:59:20: [1144:6063] <-- MAIL FROM: SIZE=574602
Wed 2011-12-07 03:59:20: [1144:6063] Performing reverse lookup on sohu.com (looking for 61.135.132.132)
Wed 2011-12-07 03:59:20: [1144:6063] D=sohu.com TTL=(10) A=[61.135.181.175]
Wed 2011-12-07 03:59:20: [1144:6063] P=010 D=sohu.com TTL=(10) MX=[sohumx.h.a.sohu.com]
Wed 2011-12-07 03:59:20: [1144:6063] P=005 D=sohu.com TTL=(10) MX=[sohumx1.sohu.com] {61.135.132.110}
Wed 2011-12-07 03:59:21: [1144:6063] D=sohumx.h.a.sohu.com TTL=(5) A=[61.135.132.110]
Wed 2011-12-07 03:59:21: [1144:6063] Spam Blocker A-record resolution of [132.132.135.61.l2.apews.org] in progress (DNS Server: 192.168.1.2)...
Wed 2011-12-07 03:59:21: [1144:6063] Spam Blocker D=132.132.135.61.l2.apews.org TTL=(35) A=[127.0.0.2]
Wed 2011-12-07 03:59:21: [1144:6063] APEWS listed, 99.7% certain it is spam
Wed 2011-12-07 03:59:21: [1144:6063] Message will be accepted and X-RBL-Warning: header will be inserted.
Wed 2011-12-07 03:59:21: [1144:6063] --> 250 , Sender ok
Wed 2011-12-07 03:59:22: [1144:6063] <-- RCPT TO:
Wed 2011-12-07 03:59:22: [1144:6063] Can't accept or relay message.
Wed 2011-12-07 03:59:22: [1144:6063] Sender not authenticated or from trusted domain/IP and recipient not a valid local account.
Wed 2011-12-07 03:59:22: [1144:6063] --> 550 , Recipient unknown
Wed 2011-12-07 03:59:22: [1144:6063] <-- RSET
Wed 2011-12-07 03:59:22: [1144:6063] --> 250 RSET? Well, ok.
Wed 2011-12-07 03:59:23: [1144:6063] <-- QUIT
Wed 2011-12-07 03:59:23: [1144:6063] --> 221 See ya in cyberspace
Wed 2011-12-07 03:59:23: [1144:6063] SMTP session successful, 126 bytes transferred.

In this case the sender is a spammer that is using the free webmail service to send crap. The email address that the spammer tried to send to was stolen from a web page that no human being would see. That is what happens spammers use automated software called robots to routinely scan IP addresses for web servers hosting web pages that contain email addresses and scraping them into their databases.

You have decide for yourself on the ratio of spam versus solicited emails via the Sohu servers. Your server, your rules. Looking at the Apews.org website, this is the text that they show for the Sohu IP address;

Entry matching your Query: E-492519
61.135.132.204 CASE: C-1
Compromised or insecure MTA
Criminal abusers have user access
SysAdmin not closing abusive accounts
No or inadequate outbound mail filter
Special Reason: List washing dirty email address database
History: Entry created 2011-09-29

So it seems they are still doing the same more than 2 months after Apews recorded their entry.

December 1, 2011

L2.APEWS.ORG False Positive #6

This is another possible false positive, as with #5 it depends on your email flow, user requirements etc. Not everyone has the same geographic distribution of email senders, however, let us take a look;

Wed 2011-11-30 22:47:41: [948:3883] Accepting SMTP connection from [121.101.151.212]
Wed 2011-11-30 22:47:41: [948:3883] Looking up PTR record for 121.101.151.212 (212.151.101.121.IN-ADDR.ARPA)
Wed 2011-11-30 22:47:42: [948:3883] D=212.151.101.121.IN-ADDR.ARPA TTL=(29) PTR=[nm3-vm0.bullet.mail.in.yahoo.com]
Wed 2011-11-30 22:47:42: [948:3883] Gathering A-records for PTR hosts
Wed 2011-11-30 22:47:42: [948:3883] D=nm3-vm0.bullet.mail.in.yahoo.com TTL=(30) A=[121.101.151.212]
Wed 2011-11-30 22:47:42: [948:3883] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Wed, 30 Nov 2011 22:47:42 -0500
Wed 2011-11-30 22:47:42: [948:3883] <-- HELO nm3-vm0.bullet.mail.in.yahoo.com
Wed 2011-11-30 22:47:42: [948:3883] Performing reverse lookup on nm3-vm0.bullet.mail.in.yahoo.com (looking for 121.101.151.212)
Wed 2011-11-30 22:47:42: [948:3883] D=nm3-vm0.bullet.mail.in.yahoo.com TTL=(30) A=[121.101.151.212]
Wed 2011-11-30 22:47:42: [948:3883] --> 250 xxx.xxx.xxx Hello nm3-vm0.bullet.mail.in.yahoo.com, pleased to meet you
Wed 2011-11-30 22:47:42: [948:3883] <-- MAIL FROM:
Wed 2011-11-30 22:47:42: [948:3883] Performing reverse lookup on yahoo.com (looking for 121.101.151.212)
Wed 2011-11-30 22:47:43: [948:3883] D=yahoo.com TTL=(60) A=[72.30.2.43]
Wed 2011-11-30 22:47:43: [948:3883] P=001 D=yahoo.com TTL=(30) MX=[mta7.am0.yahoodns.net] {98.139.175.225}
Wed 2011-11-30 22:47:43: [948:3883] P=001 D=yahoo.com TTL=(30) MX=[mta6.am0.yahoodns.net] {74.6.136.244}
Wed 2011-11-30 22:47:43: [948:3883] P=001 D=yahoo.com TTL=(30) MX=[mta5.am0.yahoodns.net] {66.94.237.139}
Wed 2011-11-30 22:47:43: [948:3883] Spam Blocker A-record resolution of [212.151.101.121.l2.apews.org] in progress (DNS Server: 192.168.1.2)...
Wed 2011-11-30 22:47:43: [948:3883] Spam Blocker D=212.151.101.121.l2.apews.org TTL=(35) A=[127.0.0.2]
Wed 2011-11-30 22:47:43: [948:3883] APEWS listed, 99.7% certain it is spam
Wed 2011-11-30 22:47:43: [948:3883] Message will be accepted and X-RBL-Warning: header will be inserted.
Wed 2011-11-30 22:47:43: [948:3883] --> 250 , Sender ok
Wed 2011-11-30 22:47:43: [948:3883] <-- RCPT TO:
Wed 2011-11-30 22:47:43: [948:3883] --> 250 , Recipient ok
Wed 2011-11-30 22:47:44: [948:3883] <-- DATA
Wed 2011-11-30 22:47:44: [948:3883] --> 354 Enter mail, end with .
Wed 2011-11-30 22:47:44: [948:3883] --> 250 Ok, message saved
Wed 2011-11-30 22:47:45: [948:3883] <-- QUIT
Wed 2011-11-30 22:47:45: [948:3883] --> 221 See ya in cyberspace
Wed 2011-11-30 22:47:45: [948:3883] SMTP session successful, 2254 bytes transferred.
Wed 2011-11-30 22:47:45: [948:3883] Shuffling message(s) into proper queue(s)
Wed 2011-11-30 22:47:45: [948:3883] Message received from nm3-vm0.bullet.mail.in.yahoo.com [121.101.151.212] with SMTP for [Size 2245] {j:\localq\x00000000000.msg}

The connecting IP address belongs to Yahoo India and is listed as a CIDR [group of IP addresses] 121.101.150.0/23 within CIDR 121.101.144.0/20. In one of the earlier posts we were talking about setup and that the free webmail providers like Yahoo, Hotmail and Google are not listed in Apews but not to mark their servers as trusted or whitelisted, simply let them connect and go through the full SMTP process on your server including rDNS / PTR lookup as you feel necessary.

This listing is therefore a contradiction and surprises us a little, hmmm... requires some further research. Email delivery involves a dialog between two email servers resulting in some lines of text referred to as the email header. A lot of spam comes from a connecting IP address that sends data showing that it received the email from one or more email servers prior. In most cases this information can not be trusted as spam software is known to deliberately falsify the information in order to mislead the recipient in gaining a more trustworthy reputation. The exceptions to this are the professional email senders referred to in an earlier post and the free webmail providers like Yahoo, Hotmail and Google. Whilst they may hide or omit useful sender identifiable data, to our knowledge they don't deliberately falsify it.

In order to further examine this possible false positive, a copy of the actual email was obtained from the recipient. The email client program revealed further headers;

>from [127.0.0.1] by smtp107.mail.in.yahoo.com with NNFMP; 01 Dec 2011 03:49:03 -0000
>from [121.101.151.237] by nm3.bullet.mail.in.yahoo.com with NNFMP; 01 Dec 2011 03:49:03 -0000
>from [202.86.5.94] by tm2.bullet.mail.in.yahoo.com with NNFMP; 01 Dec 2011 03:49:29 -0000
>from zsdguhzdpyqlnviqt (cwkpaola1972@201.241.150.55 with login) by smtp107.mail.in.yahoo.com with SMTP; 01 Dec 2011 09:19:02 +0530 IST

We are almost certain that the email was passed between the Yahoo email servers as listed above. Working down the list we see that the Yahoo server named smtp107.mail.in.yahoo.com (IP address 202.86.5.94 checks out) was the one that received the email from a computer with IP address 201.241.150.55, which belongs to VTR, an ISP in Chile. At the time of writing, IP address 201.241.150.55 has named pc-55-150-241-201.cm.vtr.net, a format usually used for dynamic IP allocations, certainly not a commercial server.

Now let us look at the content of the email, just one line of text;

ZMLNIGXGCOBMThe_Electronic-Payments-AssociationÄ›

with a link to the following website http :// goo.gl / 5z4hU.

It seems suspicious that an email sender with a Chilean IP address would login to a Yahoo India webmail server to send only one email to the user on our network who does not know the sender. The content of the email is spam and quite rightly ended up in the spam folder.

You will need to judge for yourselves whether the Yahoo India email servers send mostly solicited emails or mostly spam. In recent weeks we have noticed a huge rise in the volume of spam being delivered by the free webail providers especially AOL.

L2.APEWS.ORG False Positive #5

Found another possible false positive. I say possible because it would depend on your email flow, server policies, user requirements etc. This one is a free email service in China so the probability is that there are mostly Chinese senders which may or may not be necessary to your network and users.

Wed 2011-11-30 22:46:47: [688:3882] Accepting SMTP connection from [60.28.228.177]
Wed 2011-11-30 22:46:47: [688:3882] Looking up PTR record for 60.28.228.177 (177.228.28.60.IN-ADDR.ARPA)
Wed 2011-11-30 22:46:48: [688:3882] D=177.228.28.60.IN-ADDR.ARPA TTL=(1440) PTR=[mail228-177.sinamail.sina.com.cn]
Wed 2011-11-30 22:46:48: [688:3882] Gathering A-records for PTR hosts
Wed 2011-11-30 22:46:49: [688:3882] D=mail228-177.sinamail.sina.com.cn TTL=(1) A=[60.28.228.177]
Wed 2011-11-30 22:46:49: [688:3882] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Wed, 30 Nov 2011 22:46:49 -0500
Wed 2011-11-30 22:46:49: [688:3882] <-- EHLO mail228-177.sinamail.sina.com.cn
Wed 2011-11-30 22:46:49: [688:3882] Performing reverse lookup on mail228-177.sinamail.sina.com.cn (looking for 60.28.228.177)
Wed 2011-11-30 22:46:49: [688:3882] D=mail228-177.sinamail.sina.com.cn TTL=(0) A=[60.28.228.177]
Wed 2011-11-30 22:46:49: [688:3882] --> 250-xxx.xxx.xxx Hello mail228-177.sinamail.sina.com.cn, pleased to meet you
Wed 2011-11-30 22:46:49: [688:3882] --> 250-ETRN
Wed 2011-11-30 22:46:49: [688:3882] --> 250-AUTH=LOGIN
Wed 2011-11-30 22:46:49: [688:3882] --> 250-AUTH LOGIN CRAM-MD5
Wed 2011-11-30 22:46:49: [688:3882] --> 250-8BITMIME
Wed 2011-11-30 22:46:49: [688:3882] --> 250 SIZE 0
Wed 2011-11-30 22:46:50: [688:3882] <-- MAIL FROM: SIZE=23421
Wed 2011-11-30 22:46:50: [688:3882] Performing reverse lookup on sina.com (looking for 60.28.228.177)
Wed 2011-11-30 22:46:50: [688:3882] D=sina.com TTL=(1) A=[12.130.132.30]
Wed 2011-11-30 22:46:51: [688:3882] P=010 D=sina.com TTL=(0) MX=[freemx3.sinamail.sina.com.cn]
Wed 2011-11-30 22:46:51: [688:3882] P=010 D=sina.com TTL=(0) MX=[freemx2.sinamail.sina.com.cn] {218.30.115.106}
Wed 2011-11-30 22:46:51: [688:3882] P=010 D=sina.com TTL=(0) MX=[freemx1.sinamail.sina.com.cn]
Wed 2011-11-30 22:46:51: [688:3882] P=005 D=sina.com TTL=(0) MX=[freemx.sinamail.sina.com.cn]
Wed 2011-11-30 22:46:51: [688:3882] D=freemx3.sinamail.sina.com.cn TTL=(30) A=[60.28.2.248]
Wed 2011-11-30 22:46:52: [688:3882] D=freemx1.sinamail.sina.com.cn TTL=(30) A=[202.108.3.242]
Wed 2011-11-30 22:46:52: [688:3882] D=freemx.sinamail.sina.com.cn TTL=(0) A=[202.108.3.242]
Wed 2011-11-30 22:46:52: [688:3882] Spam Blocker A-record resolution of [177.228.28.60.l2.apews.org] in progress (DNS Server: 192.168.1.2)...
Wed 2011-11-30 22:46:52: [688:3882] Spam Blocker D=177.228.28.60.l2.apews.org TTL=(35) A=[127.0.0.2]
Wed 2011-11-30 22:46:52: [688:3882] APEWS listed, 99.7% certain it is spam
Wed 2011-11-30 22:46:52: [688:3882] Message will be accepted and X-RBL-Warning: header will be inserted.
Wed 2011-11-30 22:46:52: [688:3882] --> 250 , Sender ok
Wed 2011-11-30 22:46:53: [688:3882] <-- RCPT TO:
Wed 2011-11-30 22:46:53: [688:3882] --> 250 , Recipient ok
Wed 2011-11-30 22:46:53: [688:3882] <-- DATA
Wed 2011-11-30 22:46:53: [688:3882] --> 354 Enter mail, end with .
Wed 2011-11-30 22:47:05: [688:3882] --> 250 Ok, message saved
Wed 2011-11-30 22:47:05: [688:3882] <-- QUIT
Wed 2011-11-30 22:47:05: [688:3882] --> 221 See ya in cyberspace
Wed 2011-11-30 22:47:05: [688:3882] SMTP session successful, 23613 bytes transferred.
Wed 2011-11-30 22:47:05: [688:3882] Shuffling message(s) into proper queue(s)
Wed 2011-11-30 22:47:05: [688:3882] Message received from mail228-177.sinamail.sina.com.cn [60.28.228.177] with SMTP for [Size 23602] {j:\localq\md00000000000.msg}

As before, any news will be reported here.

November 30, 2011

L2.APEWS.ORG False Positive #4

This is only the fourth false positive in as many weeks, and it wasn't listed before as the client said it used to be in the inbox;

Mon 2011-11-28 17:33:49: [672:3108] Accepting SMTP connection from [129.228.5.23]
Mon 2011-11-28 17:33:49: [672:3108] Looking up PTR record for 129.228.5.23 (23.5.228.129.IN-ADDR.ARPA)
Mon 2011-11-28 17:33:49: [672:3108] D=23.5.228.129.in-addr.arpa TTL=(60) PTR=[mtv-newsletter4.mms.mtv.com]
Mon 2011-11-28 17:33:49: [672:3108] Gathering A-records for PTR hosts
Mon 2011-11-28 17:33:50: [672:3108] D=mtv-newsletter4.mms.mtv.com TTL=(1440) A=[129.228.5.23]
Mon 2011-11-28 17:33:50: [672:3108] --> 220 xxx.xxx.xxx ESMTP MDaemon 6.7.9; Mon, 28 Nov 2011 17:33:50 -0500
Mon 2011-11-28 17:33:50: [672:3108] <-- EHLO mtv-newsletter4.mms.mtv.com
Mon 2011-11-28 17:33:50: [672:3108] Performing reverse lookup on mtv-newsletter4.mms.mtv.com (looking for 129.228.5.23)
Mon 2011-11-28 17:33:50: [672:3108] D=mtv-newsletter4.mms.mtv.com TTL=(1440) A=[129.228.5.23]
Mon 2011-11-28 17:33:50: [672:3108] --> 250-xxx.xxx.xxx Hello mtv-newsletter4.mms.mtv.com, pleased to meet you
Mon 2011-11-28 17:33:50: [672:3108] --> 250-ETRN
Mon 2011-11-28 17:33:50: [672:3108] --> 250-AUTH=LOGIN
Mon 2011-11-28 17:33:50: [672:3108] --> 250-AUTH LOGIN CRAM-MD5
Mon 2011-11-28 17:33:50: [672:3108] --> 250-8BITMIME
Mon 2011-11-28 17:33:50: [672:3108] --> 250 SIZE 0
Mon 2011-11-28 17:33:50: [672:3108] <-- MAIL FROM:
Mon 2011-11-28 17:33:50: [672:3108] Performing reverse lookup on mms.mtv.com (looking for 129.228.5.23)
Mon 2011-11-28 17:33:50: [672:3108] D=mms.mtv.com TTL=(1440) A=[129.228.5.22]
Mon 2011-11-28 17:33:50: [672:3108] P=010 D=mms.mtv.com TTL=(1440) MX=[mailin.strongmail.west.mtvi.com] {129.228.1.185}
Mon 2011-11-28 17:33:50: [672:3108] Spam Blocker A-record resolution of [23.5.228.129.l2.apews.org] in progress (DNS Server: 192.168.1.2)...
Mon 2011-11-28 17:33:51: [672:3108] Spam Blocker D=23.5.228.129.l2.apews.org TTL=(35) A=[127.0.0.2]
Mon 2011-11-28 17:33:51: [672:3108] APEWS listed, 99.7% certain it is spam
Mon 2011-11-28 17:33:51: [672:3108] Message will be accepted and X-RBL-Warning: header will be inserted.
Mon 2011-11-28 17:33:51: [672:3108] --> 250 , Sender ok
Mon 2011-11-28 17:33:51: [672:3108] <-- RCPT TO:
Mon 2011-11-28 17:33:51: [672:3108] --> 250 , Recipient ok
Mon 2011-11-28 17:33:51: [672:3108] <-- DATA
Mon 2011-11-28 17:33:51: [672:3108] --> 354 Enter mail, end with .
Mon 2011-11-28 17:33:52: [672:3108] --> 250 Ok, message saved
Mon 2011-11-28 17:33:52: [672:3108] <-- QUIT
Mon 2011-11-28 17:33:52: [672:3108] --> 221 See ya in cyberspace
Mon 2011-11-28 17:33:52: [672:3108] SMTP session successful, 10320 bytes transferred.
Mon 2011-11-28 17:33:52: [672:3108] Shuffling message(s) into proper queue(s)
Mon 2011-11-28 17:33:52: [672:3108] Message received from mtv-newsletter4.mms.mtv.com [129.228.5.23] with SMTP for [Size 10309] {j:\localq\md00000000000.msg}
Mon 2011-11-28 17:33:52: ----------

As you can see from the headers, this is MTV's newsletter. Well, watch this space, we'll check in a day or two and report back.