Subject: Re: [testlist] Alleged spam complaint

From: James M Galvin <[email-masked]>
Date: Thu, 25 Sep 2008 11:52:17 -0400

-- On September 25, 2008 8:13:42 AM -0700 Glen <[email-masked]> wrote 
regarding Re: Alleged spam complaint --

> 1. Educate the people on these aliases about the process above, and
>    encourage them to use their own spam filtering.
> 2. Somehow modify the 200 aliases to go through postconfirm, or a spam
>    evaluation system to discard tagged spam.
> 3. Convert all of these aliases to mailing lists, and allow those
> lists    to distribute and/or filter the email.
> 4. Eliminate the aliases altogether, and use some other mechanism.

At the time of transition, my general philosophy was to make things as 
similar as possible to reduce the special cases.  We got rid of quite a 
few but clearly not all.

In this category of special cases were the "direct aliases".  There are 
two types of these.  There are those that are handled by the IETF 
servers at AMS and there are those handled by the tools server.

We converted many of the IETF server aliases to lists (the important 
ones :-), for example, the ietf chair, iab chair, and iaoc chair 
aliases.  However, there were quite a few leftover, many of which are 
probably OBE and useless (i.e., there's a fair amount of Neustar 
artifact in my opinion).  The rest of these should be reviewed and 
either eliminated or made into a list so the can be handled like 
everything else.

The issue with the tools aliases is that they expand based on 
information in the database.  The tools team has done a great service 
here, at a time when there was no other way to get the job done.  There 
are chair aliases for every working group and there are AD aliases for 
every area.

It is these aliases that I think need some kind of solution.  I don't 
think we want to eliminate them, which takes #4 off the table.  We 
can't make them lists unless we're prepared to keep the subscriber 
lists up-to-date with what's in the database, which sounds a bit like a 
cart without a horse to me.  This would be option #3.

As to whether "education" is enough or actually doing something, given 
how things went with the mailing lists I think we need to do something.

I would recommend putting the postconfirm system in front of these 
aliases.  The one thing to be careful of is that I recall there are 
automated scripts that generate messages to these aliases so we'll need 
to make sure that the appropriate From addresses are all preconfirmed. 
There may be other access control tests that would be helpful, e.g., 
making sure that the From addresses used by automated scripts never 
arrive from an external source.

Clearly this will be work, as Glen points out.  But I don't think the 
IETF wants to risk be identified or labeled as a source of spam.  That 
would be bad for everyone concerned.

Jim

_______________________________________________
Testlist mailing list
[email-masked]
https://mail.ietf.org/mailman/listinfo/testlist