[afrinic-anti-spam-discuss] BOF meeting

sulem at unijos.edu.ng sulem at unijos.edu.ng
Tue May 22 10:28:30 SAST 2007

Hi alain,

We discussed most of the issues you talked about but then we had agreed
that more discussions would continue online, we couldn't have trashed all
considering the time we had so i guess that now that the online community
is up we would continue where we stopped with more contributions from you.

Thank you.

> First of all, congrats for the great work you did.
> Some comments:
> 1- Your discussions stuck on the general aspects of spams and there was no
> mention of the specific issues african operators, users...... are facing.
> i
> know there are many which can chartered a SIG or WG
> 2-You did not talked about the sources and motivations behind the spams.
> It
> helped understand why the problem is so difficult to solve.
> 3-Fighting spams is not only a technical problems. there are also
> legal,admin... aspects, difficult to fix too.
> 4- Rewriting SMTP by IETF will not  eliminate Spams. Efforts have been
> made to
> improve SMTP, some help with e-mail trust, but no none claims to achieve
> this.
> IRTF has a research group on anti-spam
> (http://www.irtf.org/charter?gtype=rg&group=asrg) haven't chartered a WG
> for
> it :-)
> hope this helps,
> --alain
>> On 2nd May 2007 at the AfriNIC-6 meeting in Abuja Nigeria, an anti-spam
>> BOF (birds of a feather) meeting aimed at addressing specific issues
>> related to spam that are faced by African networks.
>> 21 participants attended.
>> At the meeting, it was decided to form an SIG (special interest group)
>> and a chair for the SIG was chosen - Jean Robert Hountomey.
>> It was agreed to hold further discussions on this mailing list.
>> The chair will lead discussion on suggestions to define the terms of
>> reference and a charter for the SIG.
>> This being our initial BOF, a general round table discussion on spam was
>> held. Notes below were compliled by Onime Clement.
>> General notes:
>> ==============
>> - It was stressed that with the current tools and knowledge, it is only
>> possible to
>>  reduced SPAM and not eliminated it completely.
>> Spam definitions:
>> =================
>> e-mail that is not wanted by the recipient. It was pointed out that this
>> definition would cover even normal communication from a friend if the
>> subject is not to our liking.
>> unsolicited e-mail: It was pointed out that even normal e-mail messages
>> could be classified as unsolicited when trying to contact someone for
>> the first time.
>> Bulk or Mass mailing: Even messages from other mailing lists could be
>> considered as bulk.
>> Given the above it would appear that about 10% of e-mail classified as
>> spam is highly subject to  personal interpretations while 90% is
>> considered as spam by everyone.
>> Handling SPAM from users inside our networks:
>> =============================================
>> - It is important to have/define an acceptable usage policy for our
>> network users.
>> - It is suggested that network restrict outgoing connections on port 25
>> from all clients  and permit it only from the SMTP server. For large
>> networks and visitors, outgoing connections to port 587 should be
>> permitted. - The local SMTP server should have SMTP authentication in
>> one
>> form or the other.
>> Examples include pop-before-smtp, SMTP-Auth.
>> For Single Sign On (SSO) situations, radius or kerberos5 could be
>> considered.
>> - The local SMTP server should be configured to accept connections on
>> the mail message submission port 587.
>> Handling SPAM from outside our networks:
>> ========================================
>> - INTERNET based Real time Black Lists (RBL) are good for fighting
>> outside spammers. Such RBLs are easy to get on but difficult to get off.
>> - More than 1 RBLs should be used together to improve the results.
>> - Newer Server software e.g postfix instead of sendmail could provide
>> additional benefits such as checking RBLs at SMTP connection time.
>> - Additional software such as MailScanner or amavisd could be used to
>> check email message before delivery. These software is CPU intensive.
>> - Opensource versus blackbox (paid for) solutions exists for fighting
>> spam. However, both types require maintenance/updates in order to be
>> effective.
>> - Bandwidth usage could be reduced by directly rejecting SMTP
>> connections from open-relay RBLs. When possible this could be done by an
>> up-stream SMTP server (e.g ISP or provider in Europe or U.S) especially
>> over a vsat link.
>> - HTML emails should be discouraged in order to reduce problems with
>> MailScanner or amavisd.
>> - An IETF upgrade/rewrite of the SMTP protocol could be the ultimate
>> solution to eliminating SPAM.
> _______________________________________________
> anti-spam mailing list
> anti-spam at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/anti-spam

More information about the anti-spam mailing list