Smtp1.song.fi and smtp2.song.fi, our list servers, seem to have gotten listed in the bl.spamcop.net RBL. Spamcop listings are temporary and will time out, and because of occasional major false positives (or perhaps collateral damage?) like this I don't use it to reject mail. Anyone who IS using Spamcop to reject mail has missed much of today's list traffic.
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: headerOn Thu, 2005-10-27 at 09:14 -0500, /dev/rob0 wrote:
Smtp1.song.fi and smtp2.song.fi, our list servers, seem to have gotten listed in the bl.spamcop.net RBL. Spamcop listings are temporary and will time out, and because of occasional major false positives (or perhaps collateral damage?) like this I don't use it to reject mail. Anyone who IS using Spamcop to reject mail has missed much of today's list traffic.
Oh. I changed to use smtp.song.fi because dovecot.org's IP was listed as "Dynamic/Generic IP/rDNS address" by Sorbs. Maybe I should change back then if Spamcop is used more?..
Hi Timo,
On 27 Oct 2005 at 17:27, Timo Sirainen tss@iki.fi spoke, thus:
On Thu, 2005-10-27 at 09:14 -0500, /dev/rob0 wrote:
Smtp1.song.fi and smtp2.song.fi, our list servers, seem to have gotten listed in the bl.spamcop.net RBL. Spamcop listings are temporary and will time out, and because of occasional major false positives (or perhaps collateral damage?) like this I don't use it to reject mail. Anyone who IS using Spamcop to reject mail has missed much of today's list traffic.
Oh. I changed to use smtp.song.fi because dovecot.org's IP was listed as "Dynamic/Generic IP/rDNS address" by Sorbs. Maybe I should change back then if Spamcop is used more?..
In my bitter experience, SORBS causes more damage than any of the other BLs put together and is used very heavily, SpamCop included among other, lesser lists. SpamCop listings of listhosts are usually caused by silly users who were not doing their homework properly and used the reporting interface to do the wrong thing. EuroCAUCE was even listed once! Your resolutions are to either wait for SpamCop to give up on the host, to hope that the user repents and undoes the damage by request, that someone appeals on your behalf, or to look up the IPs at SpamCop, review the tatters of the message you are allowed to look at, and to try to find the subscriber who did this with tracefields. It won't be easy, though (and judging from forum posts, you aren't likely to find the people helpful in defending a so-called sp@mmer). Anyway, you mustn't surrender. :-)
Good luck!
Cheers, Sabahattin
-- If an email tells you to forward it to all your friends, please temporarily forget that I am your friend.
Sabahattin Gucukoglu Phone: +44 20 88008915 Mobile: +44 7986 053399 Email/MSN: mail@Sabahattin-Gucukoglu.com Skype: SabahattinGucukoglu (requires authorisation, add me to your list first) SpeakFreely: Chalcedony.Sabahattin-Gucukoglu.com (Please use CELP compression if your processor allows)
On Thursday 2005-October-27 10:05, Sabahattin Gucukoglu wrote:
among other, lesser lists. SpamCop listings of listhosts are usually caused by silly users who were not doing their homework properly and used the reporting interface to do the wrong thing. EuroCAUCE was even listed once! Your resolutions are to either wait for SpamCop to give up on the host, to hope that the user repents and undoes the damage by request, that someone appeals on your behalf, or to look up the IPs at SpamCop, review the tatters of the message you are allowed to look at, and to try to find the subscriber who did this with
Again IMO the better solution is to go back to using the relay which is under his control. I don't disagree with you for the most part, but I do think he'll fare better without using the song.fi relays.
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: headerHi /dev/rob0,
On 27 Oct 2005 at 10:22, /dev/rob0 rob0@gmx.co.uk spoke, thus:
On Thursday 2005-October-27 10:05, Sabahattin Gucukoglu wrote:
among other, lesser lists. SpamCop listings of listhosts are usually caused by silly users who were not doing their homework properly and used the reporting interface to do the wrong thing. EuroCAUCE was even listed once! Your resolutions are to either wait for SpamCop to give up on the host, to hope that the user repents and undoes the damage by request, that someone appeals on your behalf, or to look up the IPs at SpamCop, review the tatters of the message you are allowed to look at, and to try to find the subscriber who did this with
Again IMO the better solution is to go back to using the relay which is under his control. I don't disagree with you for the most part, but I do think he'll fare better without using the song.fi relays.
I just checked out the reporting history, and I think you're right - there's some genuine spam coming from the host. If it's a shared host then of course any non-shared under-control individual host is preferable (since there's a smaller chance of reporters accusing it), though I still worry that SORBS has a poor record of being nice (and a good record of being "Impassively righteous"). I'm thinking of my days back on cable with a dynamic address ... but as you've said there's a better case for having the relay host unlisted because it's well-configured.
As for me, I'm pleased not to be using either BL - I use the delayed greeting trick to do what most modern BLs can't - block most zombie traffic.
Cheers, Sabahattin
-- If an email tells you to forward it to all your friends, please temporarily forget that I am your friend.
Sabahattin Gucukoglu Phone: +44 20 88008915 Mobile: +44 7986 053399 Email/MSN: mail@Sabahattin-Gucukoglu.com Skype: SabahattinGucukoglu (requires authorisation, add me to your list first) SpeakFreely: Chalcedony.Sabahattin-Gucukoglu.com (Please use CELP compression if your processor allows)
On Thursday 2005-October-27 09:27, Timo Sirainen wrote:
On Thu, 2005-10-27 at 09:14 -0500, /dev/rob0 wrote:
Smtp1.song.fi and smtp2.song.fi, our list servers, seem to have gotten listed in the bl.spamcop.net RBL. Spamcop listings are temporary and will time out, and because of occasional major false positives (or perhaps collateral damage?) like this I don't use it to reject mail. Anyone who IS using Spamcop to reject mail has missed much of today's list traffic.
Oh. I changed to use smtp.song.fi because dovecot.org's IP was listed as "Dynamic/Generic IP/rDNS address" by Sorbs. Maybe I should change back then if Spamcop is used more?..
http://www.spamcop.net/w3m?action=blcheck&ip=194.100.2.121 http://www.spamcop.net/w3m?action=blcheck&ip=194.100.2.122
Note the history, that these hosts have been listed and delisted. Chances are high that this is not a false positive per se, it is properly classified as collateral damage (non-spam coming from an exploitable server.)
In general I think neither Spamcop nor SORBS are considered prudent choices for blocking. Certainly not IMO.
And furthermore, I don't see anything wrong with dovecot.org.: good forward and reverse DNS, no RBL listings I can see:
http://www.dnsstuff.com/tools/ip4r.ch?ip=80.64.10.60
If I were you I would switch back. If you have any future SORBS problems, advise people not to use that list for blocking. :) And of course try to contact SORBS ... Mat might listen. I think he tries to be reasonable. Since you *do* have rDNS, you cannot be considered a dynamic IP by most measures.
You're not an ISP relaying for customers with probable zombied Windows machines, are you? If not your chances of being listed in a serious RBL are very slim, whereas I'd guess that song.fi's chances are medium to high.
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: headerOn Thu, 2005-10-27 at 10:16 -0500, /dev/rob0 wrote:
And furthermore, I don't see anything wrong with dovecot.org.: good forward and reverse DNS, no RBL listings I can see:
http://www.dnsstuff.com/tools/ip4r.ch?ip=80.64.10.60
If I were you I would switch back.
Switched back now.
If you have any future SORBS problems, advise people not to use that list for blocking. :) And of course try to contact SORBS ... Mat might listen. I think he tries to be reasonable. Since you *do* have rDNS, you cannot be considered a dynamic IP by most measures.
Well, I tried to remove it from the dynamic block using the automatic interface, but it says "No acceptable MX records found for dovecot.org". I guess the first problem was that I was using smtp.dovecot.org and its PTR pointed to dovecot.org, but after changing that it's still failing. Oh well.
On Thu, Oct 27, 2005 at 06:42:08PM +0300, Timo Sirainen wrote:
On Thu, 2005-10-27 at 10:16 -0500, /dev/rob0 wrote: Switched back now.
If you have any future SORBS problems, advise people not to use that list for blocking. :) And of course try to contact SORBS ... Mat might listen. I think he tries to be reasonable. Since you *do* have rDNS, you cannot be considered a dynamic IP by most measures.
Well, I tried to remove it from the dynamic block using the automatic interface, but it says "No acceptable MX records found for dovecot.org". I guess the first problem was that I was using smtp.dovecot.org and its PTR pointed to dovecot.org, but after changing that it's still failing. Oh well.
The view from here is that the sending address is no longer listed in SORBS. I can tell 'cuz my personal delivery script tags the header with a list of various interesting DNSBLs, e.g.:
X-DNSBLs: spamcop, sorbswhich tends to jump out at me. Also:
41% dnsblc 80.64.10.60
42%Anybody using SORBS to block at SMTP-time (esp. without whitelisting or taking other factors into account) deserves what they get, IMHO. It's not your responsibility to pander to them. I'm not saying it's not a valuable metric.. just, well, a race between a receiver making bad blocking decisions and a sender trying to get around those decisions helps prop up those bad decisions, and dumbs everything down.
mm (who probably makes bad blocking decisions too, but would rather fix them than having them accomodated)
Timo Sirainen wrote:
Well, I tried to remove it from the dynamic block using the automatic interface, but it says "No acceptable MX records found for dovecot.org". I guess the first problem was that I was using smtp.dovecot.org and its PTR pointed to dovecot.org, but after changing that it's still failing.
Remember that you have to wait until the original record's TTL expires before it will be active (their DNS cache still contains the old information).
You've still got some odd stuff with your DNS, see
http://www.dnsreport.com/tools/dnsreport.ch?domain=dovecot.orgfor some details. It appears that you have registered ns.dovecot.org as your authoritative server (plus the two at procontrol.fi), but within your DNS file you are claiming that dovecot.org is authoritative:
$ dig ns dovecot.org @TLD5.ULTRADNS.INFO
...snip...
;; AUTHORITY SECTION: dovecot.org. 86400 IN NS ns2.procontrol.fi. dovecot.org. 86400 IN NS ns.procontrol.fi. dovecot.org. 86400 IN NS ns.dovecot.org.
$ dig ns dovecot.org @ns.dovecot.org
...snip...
;; ANSWER SECTION: dovecot.org. 259200 IN NS ns.procontrol.fi. dovecot.org. 259200 IN NS ns2.procontrol.fi. dovecot.org. 259200 IN NS dovecot.org.
You need to make sure that what you are reporting exactly what your parent's are reporting (both in name and TTL). Feel free to respond offlist if this doesn't make any sense to you...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Thu, 27 Oct 2005, John Peacock wrote:
You need to make sure that what you are reporting exactly what your parent's are reporting (both in name and TTL).
TTL doesn't matter, and "exactly" isn't quite right -- you're allowed to add *more* NS records inside the zone to allow caches to spread load, but you do need to repeat at least all the ones in the parent zone's glue.
-- -- Todd Vierling tv@duh.org tv@pobox.com todd@vierling.name
On Thu, 2005-10-27 at 10:16 -0500, /dev/rob0 wrote:
http://www.spamcop.net/w3m?action=blcheck&ip=194.100.2.121 http://www.spamcop.net/w3m?action=blcheck&ip=194.100.2.122
Note the history, that these hosts have been listed and delisted. Chances are high that this is not a false positive per se, it is properly classified as collateral damage (non-spam coming from an exploitable server.)
Listing was caused by a single zombie host on a residental customer, even though we are rate-limiting to 60 msgs per hour with such customers it was enough to get us listed temporarily.
TDC Song Postmaster
If the servers used to send mail from the list are changed the SPF
record for the dovecot.org domain will need to be updated to reflect
the change.
Paul.
TDC Song Postmaster wrote:
Listing was caused by a single zombie host on a residental customer, even though we are rate-limiting to 60 msgs per hour with such customers it was enough to get us listed temporarily.
Just to emphasize here that the SpamCop listing was 100% legitimate, even though the Dovecot list was a classic innocent bystander. If, instead of rate-limiting, the Song.fi network instead blocked port 25 completely except from their own mail servers (for residential customers), this problem wouldn't have come up at all. There is no reason whatsoever to allow random machines (on non-static IP addresses) to send out SMTP traffic directly.
As a corporate entity, our firewalls block _all_ outbound SMTP traffic except from known mail servers. If implemented by all ISP's, the same policy would go a long way towards eliminating the effect of zombies worldwide. And if the zombies started relaying via the ISP servers, it should be straightforward to write IDS rules to locate and block the zombie traffic. Actually, for residential customers, I would require SMTP-AUTH for outbound relay, which would go even farther towards eliminating unauthorized traffic.
My 2 cents
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On Sun, 2005-10-30 at 07:13 -0500, John Peacock wrote:
Just to emphasize here that the SpamCop listing was 100% legitimate, even though the Dovecot list was a classic innocent bystander. If, instead of rate-limiting, the Song.fi network instead blocked port 25 completely except from their own mail servers (for residential customers), this problem wouldn't have come up at all.
Outbound SMTP port to Internet is blocked from residental customers, this is excactly why spam was relayed through a SMTP relay server. All major Finnish ISPs block SMTP out because it is what Finnish Communications Regulatory Authority recommends.
Actually, for residential customers, I would require SMTP-AUTH for outbound relay, which would go even farther towards eliminating unauthorized traffic.
What difference would that make because 99% users who are affected by spam proxy viruses store their username and password into email client which makes those available to any viruses like SMTP relay server is.
TDC Song Postmaster
participants (8)
-
/dev/rob0
-
John Peacock
-
Mark E. Mallett
-
Paul Isitt
-
Sabahattin Gucukoglu
-
TDC Song Postmaster
-
Timo Sirainen
-
Todd Vierling