Subject: Re: Dan Bernstein's issues about namedroppers list operation

From: <[email-masked]>
Date: Fri, 10 Jan 2003 13:30:51 -0700 (MST)

Interesting since others in this thread also seem to sensor or refuse valid
requests made to them...

its amazing we all can't just get along and "do the right thing (tm)" which
is to help build a robust global system..  much sadness because of these
childish activities and lack of acceptance of human traits.....

Q
The gadget geek

> thomas, et al,
>
> i have a bone to pick.  while dr. bernstein would most likely say that
> i am no friend to him nor to his chosen issues, the fact is that his
> complaint has some validity if you look at it edge-on rather than
> face-on.
>
>> Namedroppers is a posters-only mailing list that is run in conformance
>> with the policies outlined in
>> http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt.
>>
>> Specifically, all mail sent to namedroppers is:
>>
>> 1) first run through spamassassin. Mail that is rejected here is not
>>    archived, as the number of such messages is large. All mail sent to
>>    mailing lists on the server hosting namedroppers is run though
>>    spamassassin, so this is not a namedroppers-specific procedure.
>
> this is just wrong.  spamassassin operates at the MUA level, and as
> such, the originating MTA receives a "final OK" and drops the
> connection before spamassassin begins its job.  the MUA's only choices
> when dropping mail due to spamassassin's filtering are: issue a new
> message back to the sender to inform them of the bounce, or silently
> drop.  because most of the mail spamassassin will drop has an invalid
> sender address, choice #2 is common.
>
> for an IETF list, if submitted mail is being dropped, there must be
> notice back to the sender.  because the sender address will generally
> not be usable, the only possible choice is to issue the rejection at
> the MTA level.  this will require tighter integration of spamassassin
> into the MTA level than is currently done on randy's system, or indeed,
> currently done anywhere at all.
>
> silent drops are fatal to the IETF's policy of open discourse, and dr.
> bernstein is right to complain about that aspect of the namedroppers
> problems he is experiencing.  every time one of dr. bernstein's
> messages is dropped,  dr. bernstein's originating MTA should experience
> an SMTP delivery error and therefore have the option of informing dr.
> bernstein that such rejection has occurred.
>
> one other very minor point:
>
>> > I've noticed that Randy Bush discarded Len Budney's note on this
>> > topic:
>> > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org
>>
>> Not so.  Len's note was posted to usenet, not to the namedroppers
>> mailing list. Mail from usenet cannot be assumed to get gatewayed back
>> to the mailing list.
>
> as the usenet moderator of comp.protocols.dns.std, i set up a
> bidirectional gateway which isc operates.  this gateway is far from
> perfect, and many posts have been dropped (silently, of course) over
> the years, and anyone who wants to really ensure that their words
> appear on namedroppers should avoid the use of the usenet->namedroppers
> gateway, and mail their words directly to the namedroppers list.
>
> paul
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Jan 2003 15:40:10 -0800

Paul,

I would settle for the message being logged as dropped on some web site. 
  Or, if disk space is really an issue, I would also find it acceptable 
to have a global IETF whitelist and bounce mail from people who are not 
on it.  That having been said, I have no problem with the message 
returning as a bounce above the MTA level, so long a sa bounce is 
returned.  That means that you have to have a valid return address.  I 
don't believe the process has to be so open such that we should respond 
to invalid return addresses.

Eliot

Paul Vixie wrote:
> complaint has some validity if you look at it edge-on rather than face-on.
> 
> 
> this is just wrong.  spamassassin operates at the MUA level, and as such,
> the originating MTA receives a "final OK" and drops the connection before
> spamassassin begins its job.  the MUA's only choices when dropping mail
> due to spamassassin's filtering are: issue a new message back to the sender
> to inform them of the bounce, or silently drop.  because most of the mail
> spamassassin will drop has an invalid sender address, choice #2 is common.
> 
> for an IETF list, if submitted mail is being dropped, there must be notice
> back to the sender.  because the sender address will generally not be usable,
> the only possible choice is to issue the rejection at the MTA level.  this
> will require tighter integration of spamassassin into the MTA level than is
> currently done on randy's system, or indeed, currently done anywhere at all.
> 
> bernstein is right to complain about that aspect of the namedroppers problems
> he is experiencing.  every time one of dr. bernstein's messages is dropped, 
> dr. bernstein's originating MTA should experience an SMTP delivery error and
> therefore have the option of informing dr. bernstein that such rejection has
> occurred.
> 
>>>I've noticed that Randy Bush discarded Len Budney's note on this topic:
> as the usenet moderator of comp.protocols.dns.std, i set up a bidirectional
> gateway which isc operates.  this gateway is far from perfect, and many posts
> have been dropped (silently, of course) over the years, and anyone who wants
> to really ensure that their words appear on namedroppers should avoid the use
> of the usenet->namedroppers gateway, and mail their words directly to the
> namedroppers list.
> 
> paul
> 
> 
>