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@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

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

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@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)

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