[Mailman-Users] incorrect list-id

[Chuq Von Rospach]

At 10:59 AM -0700 6/1/2000, John W Baxter wrote:
>
>>Arguably, since it's a meta-message and not a list-message, it
>>probably ought to not have a list-id attached. it's not coming from a
>>list, but from the list's server.
>
>And, based on a complaint just now in another list (exim-users) from a
>person who gateways list messages throughout his company, there probably
>ought to be some easy filtering method (some X-xxx header in place of
>List-ID??) so that the list password doesn't get broadcast by the gateway
>process in that situation.

There's a proposed standard for this: list-probe. While it doesn't 
fit these password messages perfectly, I think it could be used (and 
perhaps this concept ought to be tossed into the discussion pot for 
list-probe). See <http://www.nisto.com/listspec/>

Actually, this is a pretty gnarly problem. If you mail to an 
exploder, all bets are off, since the person is actually not 
subscribed to the list, so the exploder list ought to follow RFC2369 
and strip the List-* headers, since they aren't relevant to the users 
on the other side of the exploder. It also, frankly, ought to replace 
them with a relevant set of their own List-* headers.

but -- does list-ID change in this kind of exploder situation?

Ack. And on the more general level, if you're sending out that 
"monthly notice about the foobar mail list", what's appropriate for 
these headers? I think there ought to be list-* headers for RFC2369, 
since that's effectively what the message is for, but no List-ID, 
since it's not attached to a list, but to the list's server. But if 
list-probe is adopted (and at first glance, I like it), it'd allow an 
exploder to recognize a message as a meta-message and strip it.

No, wait. That causes another problem. It screws up using list-probe 
for what it's really there for, probing for bogus, forwarded 
addresses. Because in the case wehre the bogus address is on the 
wrong side of the exploder, stripping messages with list-probe breaks 
the attempt to find the failing address, especially if it's bouncing 
back to the main list and not to the exploder (as it ought to -- but 
how many exploders fix the envelope properly to self-handle their own 
bounces? Not enough)

So forget that. List-probe can't be used to ID meta-messages.

So, alternative: set up a special list-ID for server messages? So 
that if you get a message from the server, it can be recognized as 
such, and exploders can therefore be trained to only forward messages 
with the appropriate list-ID, and you can safely send out the 
passwords using the meta-ID knowing the exploder will strip it.

Does that work? I realize most exploders DON'T do this work today, 
but should. But if we put the pieces in place, we make it easier to 
convince folks to do them properly...

so I guess what I'm saying is:

1) server messages go out with a listid identifying the server not a 
list on the server. As in ListID: plaidworks.com instead of ListID: 
sharks.plaidworks.com (you could potentially id the server type, as 
in mailman.plaidworks.com, but what if you happen to run a list named 
mailman on the mailman server? Perhaps formalizing the server as 
being the identifying domain is the better thought?)

2) if you're probing addresses, you use ListID set to the list, and 
List-Probe set per the proposal....

Should it be de-riguer that exploders strip all list-* headers, on 
the assumption that  they're not relevant on the other side of the 
list? I think so, since reading teh 2369 RFC says that a list 
shouldn't allow user-generated headers to be passed on, but instead 
strip them, and an exploder is really nothing more than a special 
case of a mail list...



(grant, apologize for cc:ing you in on an ongoing discussion on a 
list, but I thought it was something you ought to see, and might ave 
useful feedback on...)

-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui at plaidworks.com)
Apple Mail List Gnome (mailto:chuq at apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"