[Mailman-Developers] Re: some Python announcements are lost (LONG)

[Ron Jarrell]

At 02:24 PM 10/11/01 -0400, Barry A. Warsaw wrote:

You should post something to inn-workers@isc.org; Russ Albery, who's
working on the new nntp RFC is an INN coder.  I'm on that list too.

However, you really need a generic solution, since INN isn't the only
major news product out there, and they all have their ideas.

Plus, you're not just dealing with INN here.  From your logs:

>Jan 06 14:43:07 2001 (31278) (ToUsenet) NNTP error for list "python-list": 441 437 Binary in non-binary group
>
>Okay, so that's a start, however INN can apparently be configured to
>reject or accept other combinations of headers, so we can't rely on
>this list.

This isn't a case of INN being configured to reject extra headers; your provider
installed CleanFeed, which is an anti-spam filter, which is what issued the
437 Binary in a non-binary group error.

CleanFeed can do whatever it wants, and has all sorts of widgets for analyzing 
messages.

Some of the other errors came from situations that shouldn't have happened.
Like the gateway should never have let a message get to the news server with
a list of groups to post to, of which none exist.  That's a configuration error on the
admins part.  Also, it shouldn't have let multiple To's into the note.   The message
to old, or in the future, or unparsable also isn't particularly mm's fault - it's the same
issue we have with the archives, it's just that news, which actually computes the unix
time of a message for expiration purposes, validates the date header more than we do,
where, largely, it's just a string to us.

INN does have it's own, canonical, stupid, mail to news gateway; you might review
it's code to see what it does.  Really, it primarily gets cranky about you inserting
what's viewed as a "security" header via NNTP.  It's less cranky if you inject it directly
with inews, because you can, if suffciently trusted, just tell it 'Use these headers' and
it believes you.

Which is bsaically the same issue as the "deliver mail via sendmail vs. via smtpdirect"
thing - talk to the daemon, accept the daemon's restrictions.