The below is a belated summary of the the discussion of spamming on the lir-wg list soon after RIPE 28. I'm copying it to John Martin of TERENA as input to the BoF he is kindly organising during RIPE 29 later this month. Regards and happy new year. Mike Norris There was broad consensus that: - spammers can be clever and operate professionally - they can forge e-mail, IP addresses, even routes - they constitute at least a nuisance to users - they use inordinate levels of network and CPU resource without any charge - in some cases, the volume of traffic they generate impacts seriously on the performance of a network There were many calls for concerted action, for ISPs to back each other up, even for RIPE to take legal action against spammers. When it came to specifics, there were some points of good practice which were generally accepted and from which all could benefit. These included: - filter inbound routes on AS (lest spammers inject false routes and mail from the corresponding IP addresses) - configure sendmail to do relay only for specified hosts (to prevent spammers from using your mail server as a relay for spamming) - no-relay patches on http://www.sendmail.org/ - use sendmail patches to check From and To addresses - tighten up rules (and enforce them) for domain registration/de-registration - implement and enforce AUP and peering agreements - make address harvesting difficult e.g. www.e-scrub.com/wpoison Other anti-spamming defences, from the point of view of the recipient, included: - a daemon that checks the incoming mail queue for certain patterns of use, domains, volume of messages, etc. If a spam is detected, the daemon blocks reception of packets from the address/domain originating the spam for about 15 minutes. After that the reception is restored. - blocking SMTP access to bogus domains and addresses (not just CyberPromo) - accept the spam mail and don't deliver it On the supply side, too, ISPs suggested a range of measures to thwart spammers in their efforts to send bulk e-mail. - charge per item for delivery of e-mail with advertising material in it - regulate the number of RCPTs from a given MAIL FROM value (but how to authenticate the MAIL FROM value used?) - force dialup customers to use their ISPs SMTP relay, validate MAIL FROM value, check for forged headers, check sender identity There were those too who said that selective filtering, route denial and other practices by ISPs were not the way to go. Just because these were technically possible did not mean they had to be used; to do so could set a dangerous precedent which could be invoked in the future by outside agencies set on "controlling" the Internet. Rather, the users should be enabled to do their own filtering and many providers are equipping them with the means to do so. It is difficult, having seen the range of opinions expressed, to see a consensus about concerted action involving intervention in the mail transport mechanism, even in the European region. of spammers and dynamically blocking their routes, both of which are technically possible and already implemented in places. On balance however, it seems that the considered view is on the side of "freedom of speech". Whatever, people felt that European ISPs should act in concert and should adopt a common set of technical and administrative anti-spam measures. These would start with those listed above and might also include: - Set up a mailing list for LIR postmasters - Use digital signatures, with trusted SMTP servers - For dialup access, use TACACS+ Legal action, too, had its proponents and opponents. Instances of courts in Europe and USA finding against spammers were given, and used to suggest that RIPE might even take up legal cudgels against spammers and on behalf of its clients. As against this, there is the argument that the industry should be self-regulated, and that it should protect itself against itself. RIPE and the NCC have successfully adopted this approach to deal with IP address registration and other activities in Europe. Contributors to the discussion were: James Aldridge Sebastian Andersson Peppino Anselmi Alex Bligh Adrian Bool Pedro Ramalho Carlos Mickey Coggins Edgar Danielyan Jorgen Ericsson Ina Faye-Lund Clive D.W. Feather Kevin Ferguson Michael Ferioli gert@Space.Net Geert Jan de Groot Stephan Hermann Nick Hilliard Keith C. Howell Miroslaw Jaworski Poul-Henning Kamp Daniel Karrenberg Mihkel Kraav Andres Kroonmaa Simon Leinen Maarten E. Linthorst Javier Llopis Neil J. McRae Andre Oppermann Chris Panayis Morten Reistad Matt Ryan Luis Miguel Sequeira Paul Thornton Mario Valente Espen Vestre Francois Weil Toby Williams
Mike and LIR members, At 3:13 pm +0100 2/1/98, Mike Norris wrote:
The below is a belated summary of the the discussion of spamming on the lir-wg list soon after RIPE 28. I'm copying it to John Martin of TERENA as input to the BoF he is kindly organising during RIPE 29 later this month.
Many thanks for this. [N.B. I'm sure most of you already know, but for those that didn't, there was also a BoF at the last IETF. Results can be found at: http://www.imc.org/ietf-ube-bof/ ]
It is difficult, having seen the range of opinions expressed, to see a consensus about concerted action involving intervention in the mail transport mechanism, even in the European region. of spammers and dynamically blocking their routes, both of which are technically possible and already implemented in places.
However, it appears that many of us have been thinking the same thing for some time: the time for at least *some* deployment is here. The purpose of the BoF we proposed is to look at deployment of *existing* measures, as judging by conversations I have had with people, they can't afford to experiment with new-fangled anti-spam measures but, on the other hand, many are confounded by the myriad of tools available. If we can agree, therefore, I would like us to try to engineer this BoF towards some achievable short-term goals. [But then the purpose of having this BoF in the first place is to determine if this is feasible or not ;-) ] I'll produce a draft agenda real soon but in the meantime, any suggestions are more than welcome. Regards, John
One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people. It should be possible for people to maintain four files on their system and have sendmail DTRT for them after that: /etc/sendmail.our_ip: 192.168.1.0/24 10.0.0.0/22 /etc/sendmail.our_domains: foo.bar.com some.customer.domain.xx some.other.domain.xx /etc/sendmail.we_mx_for: bar.foo.com c.i.a.gov /etc/sendmail.people_we_dont_talk_to cyberpromo.com nancynet.com 203.23.43.0/24 203.43.43.0/22 Now that would be a worthwhile project to do... (and no before you ask, I'm way too busy with FreeBSD as it is) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!"
On Fri, 9 Jan 1998, Poul-Henning Kamp wrote:
One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people.
What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail. This would eliminate the need to store the same information to some other place, as we already have the information stored in the name service. To my understanding this is not possible to do simply by tweaking the configuration file, but it requires some patches to the actual code. And now some coffee to wake me up. :-) --sami
Sami Koskinen wrote:
One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people.
What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail. This would eliminate the need to store the same information to some other place, as we already have the information stored in the name service. To my understanding this is not possible to do simply by tweaking the configuration file, but it requires some patches to the actual code.
Such a patch exists. Get it at http://homepage.cistron.nl/~miquels/nospam/ We use it, and have been using it for quite some time now. It only needs integration with the sendmail-8.8.8-cf suite, to call Parse0 to filter local crud before applying the anti-relay rules. -- #! ##### Jan-Pieter Cornet ##### <johnpc@xs4all.net> ##### perl ++$_;$!=$_+++$_;($:,$,,$/,$*)=$!=~/.(.)...(.)(.).(.)/;$!=$_+$_; ($@,$\,$~)=$!=~/(.)(.).(.)/; $_="$,$/$:"; $@++; $~="$~$_";($_)= \$$=~/\((.)/;$|=++$_;$_++;$|++;$~="$~ $@$:";`$~$/$\$*$, $|>&$_`
Such a patch exists. Get it at http://homepage.cistron.nl/~miquels/nospam/
JC! Guru! Great minds think alike. :-) (I noted it in private email)
We use it, and have been using it for quite some time now. It only needs integration with the sendmail-8.8.8-cf suite, to call Parse0 to filter local crud before applying the anti-relay rules.
I actually just updated it for 8.8.8 (re-made the .diff and rewrote the .cf stuff so that it actually works!). Miquel van Smoorenburg has just updated his homepage. -- Niels Bakker, * * EuroNet Internet BV Network Operations * * Herengracht 208-214 * 1016 BS Amsterdam NJB9 * +31 (0)20 535 5555
participants (6)
-
Jan-Pieter Cornet
-
John Martin
-
Mike Norris
-
Niels Bakker
-
Poul-Henning Kamp
-
Sami Koskinen