Re: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy
![](https://secure.gravatar.com/avatar/51c31e93595afd261d5ae070bf1e7fbe.jpg?s=120&d=mm&r=g)
Hi, When I look at http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/ I'd probably write something that looks quite a bit different than what's currently there. For example, just starting at the top: -- "What is spam? FAQ currently says: "Spam is junk email, usually offering bogus products and invitations to pornography sites. Sometimes, spam email is used to spread viruses. You may also receive 'phishing' emails. These are emails that look like they have been sent by a legitimate organisation and attempt to fraudulently acquire sensitive information, such as passwords and credit card details." I'd suggest that the definition of "spam" that's available at http://www.spamhaus.org/definition.html is significantly stronger. -- "Should I just ignore spam?" FAQ currently says: "Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5." I'd suggest that's a passive/defeatist approach that spammers absolutely adore since it fails to put any back pressure on spammers. By NOT reporting spam, service providers hosting spam-related sites (and service providers with botted customers) get no feedback that will allow them to clean up their issues. That really needs to change. I'd suggest: "No. Consider reporting spam via a well-established spam reporting channel. This might be a "this is spam" button offered as part of your provider's web email interface, or via a third party spam reporting service such as Spamcop (http://spamcop.net/), which is free. If you want to report spam directly, you may find it helpful to see the abuse reporting addresses available from http://abuse.net/" I'd like to suggest that users report spam to appropriate government agencies, see for example: http://spamlinks.net/track-report-addresses.htm#country I would also note that encouraging user reporting is consistent with the explanation that's provided later in the FAQ under "What can I do to stop spam emails?" which goes into some detail when it comes to how to actually do manual spam reporting. -- "What can the RIPE NCC do about the spam email I have received?" FAQ currently says: "Unfortunately, the RIPE NCC can do nothing about spam email or 'phishing' email. The RIPE NCC does not send, or facilitate the sending of, spam email. Nor is it responsible for any spam you receive. It is also unable to investigate any complaints about spamming." Again, that's not the answer to this FAQ item that I'd like to see. I would like to see RIPE NCC acknowledge that it *does* have a role in combatting network abuse, particularly when it comes to ensuring that the resources it manages are not abused. For example, if RIPE NCC learns that a network resource has been acquired under fraudulent pretenses for the purpose of engaging in network abuse, or a network resource has bogus point of contact information, those behaviors are not acceptable and will result in a review by RIPE NCC and, if that abuse is confirmed, those resources will be reclaimed. Obviously that would also imply a change to "Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on?" which states "The records in the Regional Internet Registries'(RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records." If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see: -- https://www.arin.net/policy/nrpm.html#three6 "3.6 Annual Whois POC Validation "3.6.1 Method of Annual Verification "During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy." -- http://www.apnic.net/apnic-info/whois_search/abuse-and-spamming/invalid-cont... "Use this form to report invalid contact details found in the APNIC Whois Database. APNIC will take appropriate steps to try to have the database objects updated." See also http://www.apnic.net/policy/policy-environment#processing at 7.1 ("Validity of IP address delegations") -- http://lacnic.net/en/politicas/manual7-1.html ("Resource Recovery") See also http://lacnic.net/en/politicas/manual7-1.html "The organizations receiving IPs addresses from LACNIC have the commitment to keep their registration information updated. "But, in the case it is noticed that some information is invalid we ask you to communicated the fact to hostmaster@lacnic.net informing the IP address with invalid registration information." So, RIPE may not have processes for keeping their part of the global databases accurate, but other RIRs do... There are also many redundancies in the FAQ, e.g., see the "Can I stop spam?" item vis-a-vis "Should I just ignore spam?" Or "I want to know more about spam" vs. "Where can I find more information about spam" Or "How do I found out who's behind a suspect message?" vs. the tutorial on reading headers that's in "What can I do to stop spam emails?" And there are other duplications of that sort in the FAQ... I think it probably grew over time, but as stuff got slotted into the document, no deconfliction and reconciliation ever took place. I think that work to do that would strengthen the document and make it considerably stronger. Regards, Joe
![](https://secure.gravatar.com/avatar/44961e480e9953f972a244cb927cb340.jpg?s=120&d=mm&r=g)
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg- bounces@ripe.net] On Behalf Of Joe St Sauver Sent: Monday, December 12, 2011 9:22 PM To: anti-abuse-wg@ripe.net
When I look at http://www.ripe.net/data-tools/db/faq/faq-hacking- spamming/ I'd probably write something that looks quite a bit different than what's currently there.
The suggestions that followed are excellent. Thank you. (Proposal snipped due to its length but available at http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2011-December/001161.ht....) -- Thor Kottelin http://www.anta.net/
![](https://secure.gravatar.com/avatar/b5a656ea2ea262f9a97ddf6afb1f6943.jpg?s=120&d=mm&r=g)
Hello All, Joe St Sauver's comments and suggestions make perfect sense and RIPE NCC needs to follow such a sound advice. Joe's specific recommendation that "Consider reporting spam via a well-established spam reporting Channel" should be promoted by ALL user groups, and ISPs. RIPE's FAQ recommendation that "simply ignore and delete any spam emails you get" has been one of the main causes proliferation of Spam everywhere. By guiding users to sites like this, http://spamlinks.net/track-report-addresses.htm, almost anyone can report a Spam properly and keep ISP's aware of malicious traffic that passes through their servers. As Joe suggested, RIPE's FAQ must provide better guidance than reminding us to simply ignore and delete any spam emails you get. By remaining diligent, we can make this situation better for everyone. Thank you, Reza Farzan ======================
-----Original Message----- From: anti-abuse-wg-bounces@ripe.net [mailto:anti-abuse-wg-bounces@ripe.net] On Behalf Of Joe St Sauver Sent: Monday, December 12, 2011 2:22 PM To: anti-abuse-wg@ripe.net Subject: Re: [anti-abuse-wg] Spam FAQs need revision, was 2011-06 New Policy
Hi,
When I look at http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming/ I'd probably write something that looks quite a bit different than what's currently there.
For example, just starting at the top:
-- "What is spam?
FAQ currently says:
"Spam is junk email, usually offering bogus products and invitations to pornography sites. Sometimes, spam email is used to spread viruses. You may also receive 'phishing' emails. These are emails that look like they have been sent by a legitimate organisation and attempt to fraudulently acquire sensitive information, such as passwords and credit card details."
I'd suggest that the definition of "spam" that's available at http://www.spamhaus.org/definition.html is significantly stronger.
-- "Should I just ignore spam?"
FAQ currently says:
"Yes. We recommend that you simply ignore and delete any spam emails you get. Spam is a universal problem and there is not much that can be done to stop it. However, if you do want to try to find out where the spam is originating from you can follow the steps in FAQ 5."
I'd suggest that's a passive/defeatist approach that spammers absolutely adore since it fails to put any back pressure on spammers. By NOT reporting spam, service providers hosting spam-related sites (and service providers with botted customers) get no feedback that will allow them to clean up their issues. That really needs to change.
I'd suggest:
"No. Consider reporting spam via a well-established spam reporting channel. This might be a "this is spam" button offered as part of your provider's web email interface, or via a third party spam reporting service such as Spamcop (http://spamcop.net/), which is free. If you want to report spam directly, you may find it helpful to see the abuse reporting addresses available from http://abuse.net/"
I'd like to suggest that users report spam to appropriate government agencies, see for example: http://spamlinks.net/track-report-addresses.htm#country
I would also note that encouraging user reporting is consistent with the explanation that's provided later in the FAQ under "What can I do to stop spam emails?" which goes into some detail when it comes to how to actually do manual spam reporting.
-- "What can the RIPE NCC do about the spam email I have received?"
FAQ currently says:
"Unfortunately, the RIPE NCC can do nothing about spam email or 'phishing' email. The RIPE NCC does not send, or facilitate the sending of, spam email. Nor is it responsible for any spam you receive. It is also unable to investigate any complaints about spamming."
Again, that's not the answer to this FAQ item that I'd like to see.
I would like to see RIPE NCC acknowledge that it *does* have a role in combatting network abuse, particularly when it comes to ensuring that the resources it manages are not abused. For example, if RIPE NCC learns that a network resource has been acquired under fraudulent pretenses for the purpose of engaging in network abuse, or a network resource has bogus point of contact information, those behaviors are not acceptable and will result in a review by RIPE NCC and, if that abuse is confirmed, those resources will be reclaimed.
Obviously that would also imply a change to
"Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on?"
which states
"The records in the Regional Internet Registries'(RIR) databases are entered and maintained by the organisations that receive IP addresses from each RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The RIPE NCC has no power to update any of these records."
If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see:
-- https://www.arin.net/policy/nrpm.html#three6
"3.6 Annual Whois POC Validation
"3.6.1 Method of Annual Verification
"During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy."
-- http://www.apnic.net/apnic-info/whois_search/abuse-and-spammin g/invalid-contact-form
"Use this form to report invalid contact details found in the APNIC Whois Database. APNIC will take appropriate steps to try to have the database objects updated."
See also http://www.apnic.net/policy/policy-environment#processing at 7.1 ("Validity of IP address delegations")
-- http://lacnic.net/en/politicas/manual7-1.html ("Resource Recovery")
See also http://lacnic.net/en/politicas/manual7-1.html
"The organizations receiving IPs addresses from LACNIC have the commitment to keep their registration information updated.
"But, in the case it is noticed that some information is invalid we ask you to communicated the fact to hostmaster@lacnic.net informing the IP address with invalid registration information."
So, RIPE may not have processes for keeping their part of the global databases accurate, but other RIRs do...
There are also many redundancies in the FAQ, e.g., see the "Can I stop spam?" item vis-a-vis "Should I just ignore spam?"
Or "I want to know more about spam" vs. "Where can I find more information about spam"
Or "How do I found out who's behind a suspect message?" vs. the tutorial on reading headers that's in "What can I do to stop spam emails?"
And there are other duplications of that sort in the FAQ... I think it probably grew over time, but as stuff got slotted into the document, no deconfliction and reconciliation ever took place. I think that work to do that would strengthen the document and make it considerably stronger.
Regards,
Joe
======= Email scanned by PC Tools - No viruses or spyware found. (Email Guard: 9.0.0.888, Virus/Spyware Database: 6.18870) http://www.pctools.com/ =======
![](https://secure.gravatar.com/avatar/2041cdaf7dd3b3bffdba2996694df63f.jpg?s=120&d=mm&r=g)
Joe, It's a bit of a tangent, but... On Mon, 2011-12-12 at 11:22 -0800, Joe St Sauver wrote:
If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see:
-- https://www.arin.net/policy/nrpm.html#three6
"3.6 Annual Whois POC Validation
"3.6.1 Method of Annual Verification
"During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy."
What a great method for finding networks that are poorly monitored and maintained! Simply check ARIN's Whois database until you find networks with POC that are marked as invalid! I hope that RIPE does not adopt this address-hijacking-friendly technique. :( -- Shane
![](https://secure.gravatar.com/avatar/7464051f6e3699c7fe501681b53d8c48.jpg?s=120&d=mm&r=g)
security by obscurity you mean? --srs (iPad) On 13-Dec-2011, at 16:22, Shane Kerr <shane@time-travellers.org> wrote:
Joe,
It's a bit of a tangent, but...
On Mon, 2011-12-12 at 11:22 -0800, Joe St Sauver wrote:
If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see:
-- https://www.arin.net/policy/nrpm.html#three6
"3.6 Annual Whois POC Validation
"3.6.1 Method of Annual Verification
"During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy."
What a great method for finding networks that are poorly monitored and maintained! Simply check ARIN's Whois database until you find networks with POC that are marked as invalid!
I hope that RIPE does not adopt this address-hijacking-friendly technique. :(
-- Shane
![](https://secure.gravatar.com/avatar/71d8bf1aa43d8a3d50564475369f935c.jpg?s=120&d=mm&r=g)
Suresh Ramasubramanian wrote:
security by obscurity you mean?
this may be seen as one end of a stick - offering the info on a silver platter may be seen as the other end :-) wilfried
--srs (iPad)
On 13-Dec-2011, at 16:22, Shane Kerr <shane@time-travellers.org> wrote:
Joe,
It's a bit of a tangent, but...
On Mon, 2011-12-12 at 11:22 -0800, Joe St Sauver wrote:
If nothing else, that FAQ answer should *at least* be updated to correct factual inaccuracies because at least *some* other RIRs *DO* check and/or correct inaccuracies in their databases, e.g., see, in the case of ARIN, APNIC and LACNIC, see:
-- https://www.arin.net/policy/nrpm.html#three6
"3.6 Annual Whois POC Validation
"3.6.1 Method of Annual Verification
"During ARINs annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy."
What a great method for finding networks that are poorly monitored and maintained! Simply check ARIN's Whois database until you find networks with POC that are marked as invalid!
I hope that RIPE does not adopt this address-hijacking-friendly technique. :(
-- Shane
![](https://secure.gravatar.com/avatar/154fec75235d86c7ca1211152a8295fd.jpg?s=120&d=mm&r=g)
I hope that RIPE does not adopt this address-hijacking-friendly technique. :(
One could argue that some form of validation is better than no validation at all. The follow up question is 'should this data be made readily available to the community' the way ARIN does, or are there other ways to raise the bar for your doom scenario. Pepijn +++++++++++++++++++++++++++++++++++++++++++++ Disclaimer Dit e-mailbericht kan vertrouwelijke informatie bevatten of informatie die is beschermd door een beroepsgeheim. Indien dit bericht niet voor u is bestemd, wijzen wij u erop dat elke vorm van verspreiding, vermenigvuldiging of ander gebruik ervan niet is toegestaan. Indien dit bericht blijkbaar bij vergissing bij u terecht is gekomen, verzoeken wij u ons daarvan direct op de hoogte te stellen via tel.nr 070 315 3500 of e-mail mailto:mail@opta.nl en het bericht te vernietigen. Dit e-mailbericht is uitsluitend gecontroleerd op virussen. OPTA aanvaardt geen enkele aansprakelijkheid voor de feitelijke inhoud en juistheid van dit bericht en er kunnen geen rechten aan worden ontleend. This e-mail message may contain confidential information or information protected by professional privilege. If it is not intended for you, you should be aware that any distribution, copying or other form of use of this message is not permitted. If it has apparently reached you by mistake, we urge you to notify us by phone +31 70 315 3500 or e-mail mailto:mail@opta.nl and destroy the message immediately. This e-mail message has only been checked for viruses. The accuracy, relevance, timeliness or completeness of the information provided cannot be guaranteed. OPTA expressly disclaims any responsibility in relation to the information in this e-mail message. No rights can be derived from this message.
participants (7)
-
Joe St Sauver
-
Reza Farzan
-
Shane Kerr
-
Suresh Ramasubramanian
-
Thor Kottelin
-
Vissers, Pepijn
-
Wilfried Woeber, UniVie/ACOnet