[afrinic-anti-spam-discuss] BOF meeting

[Alain Patrick AINA]

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.