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

[Barry A. Warsaw]

>>>>> "RJ" == Ron Jarrell <jarrell@vt.edu> writes:

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

Okay cool.  Let me see if I can formulate a coherent question... :)

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

Agreed.  That's what standards are for though, right? :)

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

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

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

Ah, I didn't know about CleanFeed.

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

Some of these things are just due to the fact that a message shows up
on email first, where the rules MTAs impose are much more lenient.  So
the header rejects are where the NNTP server has stricter rules that
don't make much sense for an email message.  E.g. email has duplicate
To: and Cc: headers all the time.  Why an NNTP server would reject
duplicate To: and Cc: headers, when it doesn't care about those for
Netnews purposes, is confounding.

But in general, I can clean up headers, and in fact my quick patch on
SF for MM2.0.6 seems to have stopped the bulk of the rejects nicely
(header rejects were much more common than binary filters or other
issues).

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

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

Agreed, however it would be nice to have a standard that says "posting
hosts may not have these headers", or "must not have more than one of
those other headers".  What bothers me is that the massaging of the
message must rely on implementation quirks instead of standards.

So I guess a good question for inn-workers is: what will the draft
standard say about required or prohibited headers?

-Barry