[afrinic-anti-spam-discuss] BOF meeting

[sulem at unijos.edu.ng]

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.
Mary-Jane.

>
>
>
> 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
>