Re: Spam to this list
Shachar Shemesh [EMAIL PROTECTED] said, in message [EMAIL PROTECTED]: Reject codes were very common once. Then they were recommended against. They were recommended against for a reason, that reason being that they expose the user base to password and other guessing. Who recommended this?! What on earth makes you think that a 5xx return code lets you determine either usernames or passwords while a generated bounce doesn't? On all the mail administrators' mailing lists I'm on, people always recommend using 5xx in preference to sending a bounce, for all the obvious reasons. If SpamCop is now listing people who send collateral spam, I think that's no bad thing. It'll certainly cut down the number of Joe Jobs I end up on the receiving end of... I know a determined attacker could conceivably probe the existance of addresses using a dictionary attack and looking at the *text* following the 5xx response, but this is hard work for the attacker and very easy to prevent at the server (for example, after 5 invalid RCPT TO: addresses in a single message, aber.ac.uk will respond Too many invalid addresses unconditionally. Throw in a teergrube and they can spend weeks doing what a google search could achieve in seconds). Cheers, Alun. -- Alun Jones [EMAIL PROTECTED] Systems Support, (01970) 62 2494 Information Services, University of Wales, Aberystwyth -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
Alun wrote: Shachar Shemesh [EMAIL PROTECTED] said, in message [EMAIL PROTECTED]: Reject codes were very common once. Then they were recommended against. They were recommended against for a reason, that reason being that they expose the user base to password and other guessing. Who recommended this?! I'm replying off list, to tune down the noise. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
Paul Slootman wrote: There's a difference between giving a 5xx response during SMTP, and first accepting a message and then later bouncing it to the (supposed) envelope sender. I believe spamcop is protesting the latter, not the first. I agree with them. 20% of the junk I get are bogus bounces. For good or ill, SMTP is a store-and-forward mechanism. The node in the process of delivering to the node which issues the rejection is no longer in a position to issue its own rejection. Instead, it must send a separate bounce message to the - claimed, unfortunately - sender. - Andrew -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
On Tue 19 Apr 2005, Andrew Gideon wrote: Paul Slootman wrote: There's a difference between giving a 5xx response during SMTP, and first accepting a message and then later bouncing it to the (supposed) envelope sender. I believe spamcop is protesting the latter, not the first. I agree with them. 20% of the junk I get are bogus bounces. For good or ill, SMTP is a store-and-forward mechanism. The node in the process of delivering to the node which issues the rejection is no longer in a position to issue its own rejection. Instead, it must send a separate bounce message to the - claimed, unfortunately - sender. Yes, and if the first system in the chain would do it, spam wouldn't leave the originating system. (The first system is often an open relay, or my system in case of zombie PCs that are sending out the spam.) Paul Slootman -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
John E. Malmberg wrote: The I.P. address is listed in bl.spamcop.net as hitting spamtraps. Just so you know, spamcop view bounces as spam. According to them, you should never send bounces. I believe the right approach is to convince admins to drop spamcop from their RBL list, rather than remove the very essential NACK SMTP has from all servers, as per spamcop's request. -John [EMAIL PROTECTED] Personal Opinion Only Same here. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
Continuing this off-topic issue: On Mon 18 Apr 2005, Shachar Shemesh wrote: John E. Malmberg wrote: The I.P. address is listed in bl.spamcop.net as hitting spamtraps. Just so you know, spamcop view bounces as spam. According to them, you should never send bounces. I believe the right approach is to convince admins to drop spamcop from their RBL list, rather than remove the very essential NACK SMTP has from all servers, as per spamcop's request. There's a difference between giving a 5xx response during SMTP, and first accepting a message and then later bouncing it to the (supposed) envelope sender. I believe spamcop is protesting the latter, not the first. I agree with them. 20% of the junk I get are bogus bounces. Paul Slootman -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
Shachar Shemesh wrote: John E. Malmberg wrote: The I.P. address is listed in bl.spamcop.net as hitting spamtraps. Just so you know, spamcop view bounces as spam. According to them, you should never send bounces. I think you will find a large amount of mail server administrators agree with that, especially the ones that have been DDOS from spammers and viruses impersonating their domain. A few years ago I saw a posting in the spamcop.net forum reporting that AOL had posted in the SPAM-L mailing list that AOL was changing their system to only use SMTP rejects and that they were going to stop generating bounces because they recognized that the practice is abusive to the rest of the internet. Spamcop.net only changed their policy a few months ago. Spamhaus.org has also listed I.P. addresses that are bouncing all detected spam and viruses. As near as I can tell, they started doing before spamcop.net did, and it seemed to be triggered by a company selling an anti-spam/virus appliance that was configured by default to abusively bounce detected spam and viruses to what was known to be forged addresses. At least one domain, test.com was basically DDOSed to death for a while because of the bounces from spammers and viruses forging addresses. I believe the right approach is to convince admins to drop spamcop from their RBL list, rather than remove the very essential NACK SMTP has from all servers, as per spamcop's request. The essential SMTP NACK is not what is the problem as long as it is done during the SMTP connection using reject codes. Issuing a SMTP reject code for undeliverable messages will never cause a spamcop.net listing. The SMTP bounce is an artifact from the time when third party open relays where also in common use. At that time, it was needed by the third party open relay to return the non-delivery message. The end mail server would use an SMTP reject, and the third party open relay would generate the bounce message. Now, almost no mail servers will accept e-mail from known open relays, so when they can not deliver an e-mail, if they use an SMTP reject code, then the sender's mail server, which should trust the sender will generate the bounce message. If these bounces from the sender's mail server are going to forged addresses, then there is a security problem on the sending network that needs to be fixed. With almost all spam and viruses, there is no mail server to generate bounces from getting an SMTP reject. At current estimates on internet, a mail server is now getting 3 spam/virus messages for every real message that is attempted to be delivered. Which means if a mail server is bouncing instead of using SMTP rejects, it is bounce relaying 3 spam/virus messages for every real one, and those messages are being bounced to other victims. And since medium to large networks pay a metered rate for their internet connection, bouncing instead of using SMTP rejects will significantly increase their operating costs as it will cause them to pay for the bandwidth for 6 spam/virus e-mails for every 1 real e-mail that they receive. Using SMTP rejects and DNSbls eliminates almost all of that cost from their operation. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
John E. Malmberg wrote: The essential SMTP NACK is not what is the problem as long as it is done during the SMTP connection using reject codes. Issuing a SMTP reject code for undeliverable messages will never cause a spamcop.net listing. Reject codes were very common once. Then they were recommended against. They were recommended against for a reason, that reason being that they expose the user base to password and other guessing. When Spamcop was confronted with spammers harvesting email using rejection codes, Julian responded with the laughable I don't know of spammers who do that. What? Not to mention the fact that secondary MXes are impossible to reject during SMTP, as are virtual domains (for all practical purposes), later filters, and many many many other cases. Julian's solution is either don't provide NACK or hold the original SMTP until you know what to reply. I'm sorry, but both answers are laughably sad, and effectively mean the end of SMTP. I know, it's bad to be bombarded with bounces. I've been there myself. Destroying the reliability of SMTP for this high cause, however, is something I cannot abide by. I have heard of enough cases where important emails vanished without leaving a trace to consider this a trivial or unimportant problem. The SMTP bounce is an artifact from the time when third party open relays where also in common use. At that time, it was needed by the third party open relay to return the non-delivery message. No. See above. I won't mention qmail again, because Julian seems to not mind the fact that it's the only safe MTA around, but the simple fact is that any time you need to perform processing in order to accept or reject an email, you need to accept the mail and then decide. Keeping a TCP connection open just so you can put in a reject code in the protocol opens you up for DoS, as well as threaten the very delivery due to timeouts. And, you have not mentioned secondary MXes and downed networks yet. Now, almost no mail servers will accept e-mail from known open relays, so when they can not deliver an e-mail, if they use an SMTP reject code, then the sender's mail server, which should trust the sender will generate the bounce message. It's a great theory. Too bad it doesn't cover all cases. If these bounces from the sender's mail server are going to forged addresses, then there is a security problem on the sending network that needs to be fixed. No, there is a bandwidth problem. I agree that it's a problem, but I totally disagree with the solution. And since medium to large networks pay a metered rate for their internet connection, bouncing instead of using SMTP rejects will significantly increase their operating costs as it will cause them to pay for the bandwidth for 6 spam/virus e-mails for every 1 real e-mail that they receive. Using SMTP rejects and DNSbls eliminates almost all of that cost from their operation. I don't see the difference. One way or the other, SMTP is shot. If someone shoots down a protocol I need, I call him the enemy of the public. So far it has been spammers. Now it's spammers and Spamcop. My mail server doesn't bounce viruses. The reason is that I can detect viruses with close to 0% false positives, so I feel fairly confident in sending them to /dev/null. Unfortunately, spam does not enjoy this rate of false positives. What's more, even if it did, the occasional false negative would mean that I would still get blacklisted. Look, I chose a difficult to understand name for my company (Lingnu). As a result, many times, if I'm telling someone my email address over the phone, they'll get it wrong. It didn't used to be a problem. If one in four got it wrong, they would get a bounce and call me. Not any more. One of the domains around mine sends all incoming email to /dev/null, and people are mad at me for not responding to my emails. Do tell me that this is ok with you, or that you don't think that SMTP loses a lot from it's functionality (even more so than because of Spam) as a result. Again, this is without bringing qmail into the picture. Qmail, as a direct result of a design that keeps security in mind, cannot send rejections inline. The daemon accepting the mail simply doesn't know what's behind it. It's an unprivileged drown that take the emails and queue them, not having any idea what will happen to them afterwards. In an environment where spammers exploit security holes to infect computers with spam sending zombies, telling an MTA admin to switch to something less secure because you don't like something defined by the RFC is counter-productive and does more to hurt spam fighting than to help it. Now, this is getting off topic for rsync, so please do feel free to send me your reply privately. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To unsubscribe or change options:
Spam to this list
Unfortunately I must report that legitimate emails are also blocked by sbl-xbl.spamhaus.org. After exchanging a number of private emails with [EMAIL PROTECTED], my next answer was blocked without reason at all. [EMAIL PROTECTED] -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
Christian Nekvedavicius wrote: Unfortunately I must report that legitimate emails are also blocked by sbl-xbl.spamhaus.org. If you e-mails are being blocked by a sbl-xbl.spamhaus.org listing then you should be complaining loudly to your network provider. It my help if you find out what list(s) that the I.P. address that is being listed is really on. The sbl-xbl.spamhaus.org is combination of three lists: sbl = sbl.spamhaus.org xbl = opm.blitzed.org and cbl.abuseat.org To get on the sbl portion, an internet provider has either had to work at being a bad network citizen and have been ignoring legitimate abuse complaints or is actively and knowingly assisting a spammer. The sbl is very conservative and will only list a production mail server as a last resort. To get on the opm.blitzed.org means that I.P. address has recently been tested and confirmed to be an open proxy, which basically means that it is providing unlimited free e-mail and other network services to every criminal on the internet. opm.blitzed.org will retest on request. To get on cbl.abuseat.org, the I.P. in question must have sent e-mail to a spamtrap address, and the contents of that e-mail was determined not to be from an auto-responder that is generating a new mail in response to spam or a virus. About the only way to get on the cbl.abuseat.org is for the I.P. listed to either be controlled by a virus or controlled by a spammer through an open proxy. Removal from the cbl.abuseat.org is done through a webform, one removal is allowed per week. So about only way that a mail server can get on the sbl-xbl.spamhaus.org is if it is under the control of a virus or a spammer. Now looking at the mail server that your post went through: It is not listed in the sbl-xbl.spamhaus.org. opm.blitzed.org claims that they have never listed the I.P. address and have never been requested to do a test on that I.P. address. The cbl.abuseat.org also shows that is is not listed currently. No other information is available. The I.P. address is listed in bl.spamcop.net as hitting spamtraps. There appears to be 5 outgoing mail servers for that domain, and that means that currently you have a 20% chance of your mail being rejected if you mail someone whose postmaster is using the spamcop blocking list for rejection instead of scoring. At least three of the mail servers have recently sent spam to spamtraps operated by the opm.blitzed.org. This caused proxy tests to be performed on them which they passed. 195.202.32.15 listed in bl.spamcop.net (127.0.0.2) If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 21 hours. Causes of listing Maximum listing time after the last spam report is 48 hours. Minimum listing time is 1/2. The time between varies based on an algorithm that takes into account prior listings of that I.P. address, and the amount of spam reported from it. * System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop) To get listed this way, it means that the amount of spam hitting spamcop.net spamtraps exceeded 1% of the volume of e-mail from that I.P. from various monitoring points on the Internet. For an ISP mail server, 1% is usually a large number. Senderbase is reporting measuring well over 10,000 e-mails per day from that I.P. Additional potential problems (these factors do not directly result in spamcop listing) * System administrator has already delisted this system once Because of the above problems, express-delisting is not available Listing History In the past 17.7 days, it has been listed 3 times for a total of 38 hours For a production mail server to get listed by spamcop.net this many times in that short of time, it indicates that there is a problem at that mail server, either it is relaying spam, or it is abusively bouncing spam and virus reports to what are known to be forged e-mail addresses instead of following the standard practice and using SMTP rejects. Or they have a clueless user that is using the fake bounce function that some poorly written anti-spam software has. Of course they would have had to bounce a lot of spam/viruses in a short time to cause a listing. Sending bounces or virus notifications to forged addresses are effectively a denial of service attack against the user that the spam or virus impersonated. It looks like someone delisted the I.P. address from the spamcop.net list with out fixing the problem that resulted in the listing. Getting an ISP mail server listed on spamcop.net is also rare, but does happen, but generally there is a large period of time (Think months/years) between listings unless there is a chronic problem with the configuration or security of that server. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before
Re: Spam to this list
Martin Pool wrote: John Van Essen wrote: The policy is to block as much spam as possible without blocking legitimate posts. A 100% solution is impossible, even if we had human moderation (humans make mistakes). I am seeing reports on news.admin.net-abuse.email from Steve Linford that he is getting at least 99% accuracy in removing spam with zero loss of real e-mail. He is removing about 85% of the spam with DNSbls so that it does not even get inside of the mail server, and then using SpamAasssin 3.0 with it's new test on URLs inside of mail, where if the URL resolves to an IP address that is known to be controlled by a spammer, the e-mail is rejected. And he is reporting that he is not using a DHCP list for doing rejections. The first one has been in the dul.dnsbl.sorbs.net blacklist since Oct. I use these 4 DNS-based blacklists in the mail server that I manage: sbl-xbl.spamhaus.org I have not ever seen a report of an incorrect listing in the xbl.spamhaus.org. I have only seen one reported error in several years of the sbl.spamhaus.org and it was corrected with in 1/2 hour of this being pointed out on news.admin.net-abuse.email. It is a merging of 3 dnsbls for convenience. sbl.spamhaus.org - Hand maintained list of I.P. addresses controlled by spammers. The sbl.spamhaus.org is probably now the most widely used dnsbl in the world. An ISP has to work hard at supporting spam to get any of it's IP addresses listed in the sbl.spamhaus.org. xbl.spamhaus.org is a combination of opm.blitz.org and cbl.abuseat.org. The cbl.abuseat.org runs spamtraps that filter out auto-responders. In the time it has been in existence, I have seen zero reports of an incorrect listing. It will delist on request once per week, and listings age off. The opm.blitz.org verifies that the I.P. address is an open proxy, and ages off old listings. list.dsbl.org This is a list of known compromised I.P. addresses where no responsible party has demonstrated they have an RFC compliant mailbox set reading abuse complaints. If a real mail server is listed, it means that it is either an active compromised machine, or that their is no one that is reading messages to their abuse or postmaster e-mail addresses. It is extremely widely used to reject e-mail, possibly the most used after the spamhaus.org. dul.dnsbl.sorbs.net In the past, the dul.dnsbl.sorbs.net used to run a higher false positive rate. Now it is almost not measurable. dul.dnsbl.sorbs.net now allows owners of mistaken static entries to use a webform to remove them as long as they can show a forward DNS name pointing to that I.P. with a long enough TTL to show it is static. Currently a listing in dul.dnsbl.sorbs.net indicates well over a 99% chance of spam. web.dnsbl.sorbs.net I have heard nothing good or bad about that one. In the spam I sent through spamcop.net in the past year, I recall seeing it only flag one spam that was not detected by either the cbl.abuseat.org or njabl as being in that DNSBL. From what I have seen, the only zone in sorbs that is likely to cause real e-mail to be rejected is the spam.dnsbl.sorbs.net as it is usually listing multi-hop exploits of the mail servers of major ISP's and they have to jump through hoops to get off of it. The other SORBS zones do not require such extra actions. And they have helped a LOT. The other 3 have no reverse DNS entries. A machine with no reverse DNS that is sending email is not very likely to be a legitimate email server. It's much more likely a compromised machine on a clueless ISP's network. Rejecting email from those unidentified machines also has helped a lot. Using any of those measures alone tends to block legitimate posters, Can you find a legitimate post that was blocked by the sbl-xbl.spamhaus.org? I have not heard of an error on that list yet. From the reports that I have seen on the various e-mail forums, reverse DNS is now an RFC requirement for operating any server on the public internet. Networks with no rDNS are demonstrating that they do not understand how to be properly connected to the internet and have proven to be a large source of problems. The fastest way to get that problem fixed is to take AOL's approach and refuse all e-mail with no rDNS on it at all. particularly those running their own mail server, which to my mind is a greater harm than letting ocassional spam go through. Our purpose here is to run a mailing list, not punish ISPs. So we use all the things you named as part of a weighted score. Actually what is a result is that you are allowing the list recipients to be punished by incompetent ISP's. At some point, it is not worth attempting to try to find a potential real e-mail from a network that has allowed spammers to infest it by either neglect or by willful act. If you can put a [SPAM?] tag on mail trapped by a the following algorithm, I would be surprised if any real postings
Spam to this list
Hi, I'm not sure what the policy of this list is and I bet everyone has a spam filter, so nobody might have noticed, but we got spammed. Can anyone send mail to the list or do you have to subscribe first ? -- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
On Fri, 25 Mar 2005 20:42:19 +0100 (CET), Dag Wieers dag-at-wieers.com |Rsync List| ... wrote: I'm not sure what the policy of this list is and I bet everyone has a spam filter, so nobody might have noticed, but we got spammed. Can anyone send mail to the list or do you have to subscribe first ? Anyone can send mail, including phishers. I think we all got this one an hour ago or so: - We regret to inform you that your eBay account could be suspended if you don't re-update your account information. To resolve this problems please click here and re-enter your account information. If your problems could not be resolved your account will be suspended for a period of 3-4 days, after this period your account will be terminated. - This nicely done phish uses http://lenix.brinkster.net/ebay/redirect.php to collect your Ebay login information. The rsync list is one of my higher sources of spam, but I also understand the reasoning behind keeping the list open. The list managers have installed filters, but they can only do so much. For a complete history of spam discussions here, try this Google search: http://www.google.com/search?as_q=spamnum=10as_sitesearch=lists.samba.org -- Steve -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Spam to this list
John Van Essen wrote: Off list to rsync list owner (feel free to reply on-list if you like): On Fri, 25 Mar 2005, Dag Wieers [EMAIL PROTECTED] wrote: Hi, I'm not sure what the policy of this list is and I bet everyone has a spam filter, so nobody might have noticed, but we got spammed. The policy is to block as much spam as possible without blocking legitimate posts. A 100% solution is impossible, even if we had human moderation (humans make mistakes). It seems that these posts got through during a surge of spam when the filter hit its maximum-process limit. During the day of the 24th more than 60 spam messages to the list were blocked. I got several. Delivered to the mailing list from: cpe-24-243-54-175.satx.res.rr.com [24.243.54.175] unknown [219.252.105.93] unknown [218.59.89.16] unknown [200.159.206.55] The first one has been in the dul.dnsbl.sorbs.net blacklist since Oct. I use these 4 DNS-based blacklists in the mail server that I manage: sbl-xbl.spamhaus.org list.dsbl.org dul.dnsbl.sorbs.net web.dnsbl.sorbs.net And they have helped a LOT. The other 3 have no reverse DNS entries. A machine with no reverse DNS that is sending email is not very likely to be a legitimate email server. It's much more likely a compromised machine on a clueless ISP's network. Rejecting email from those unidentified machines also has helped a lot. Using any of those measures alone tends to block legitimate posters, particularly those running their own mail server, which to my mind is a greater harm than letting ocassional spam go through. Our purpose here is to run a mailing list, not punish ISPs. So we use all the things you named as part of a weighted score. -- Martin signature.asc Description: OpenPGP digital signature -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
