In <v04020a00b2fb4c378c03(_at_)[130(_dot_)237(_dot_)161(_dot_)11]> Jacob Palme
<jpalme(_at_)dsv(_dot_)su(_dot_)se> writes:
At 12.31 +0100 99-02-25, Charles Lindsey wrote:
What about messages arriving other than by SMTP (even uucp is still around
in some places)? In any case, if lists are nested, the SMTP address that
arrives may be from another list, whereas you may actually want to filter
according to the actual posters to that other list.
If you have nested lists, you usually have a top node,
where all new submissions should arrive. This top node
cannot let only subscribers post, because the subscribers
are on lists lower in the hierarchy.
I had not thought of this problem. A solution would be if
all the nested lists were members of each other, or if the
links in the nesting tree were doubledirected. Then anyone
could submit to any of the lists, and have the message sent
to all the other lists. Each list could then be set up to
check that only SMTP senders of its own subscribers
(including all the other lists) can send. This structure is
not so common, but would be a solution and should certainly
be described.
If you have a hierarchical graph without loops, then all
new submissions should send to the top node, so lists below
the top node should only accept submission whose SMTP
sender is the top node!
No, I don't think that is right. Let us take an example. Both you and I
are on both of the lists ietf-822 and usenet-format, and we post to
each of those lists independently of the other.
Now suppose there is a topic that should be discussed on both lists (and
actually, this is a real situation, because I am about to start such a
topic in a few days). One way would be to create a new list (call it
usenet-plus-mail) whose only subscribers are ietf-822 and usenet-format.
So if you want to post to both lists, you post instead to
usenet-plus-mail, but you continue posting to the single lists for topics
that only apply to one of them (well, there may be other ways of
arranging things - this is just a possible example).
Now the new list receives posts from all sorts of people that it does not
know about. So there is no point filtering on the SMTP address or on the
From address, or anything else, there. The lower lists only know (by SMTP)
that the posting came from usenet-plus-mail, which they should be happy
with. They may, however, look at the from line and match it against their
blacklists and whitelists (though in this case there is not much point,
because lots of the submissions may be from people who normally live on
the "other" list).
I don't think there really IS a solution to this one. I doubt the one you
suggested above would do any good.
8. Loop Control
Is this commonly used? I thought the common idea was that mailing list
expanders should not add Resent- headers. Am I wrong?
Hmmm! I have been told by somebody else that this was not so, but it is
not my reading of DRUMS:
"3.6.6 Resent fields
Resent fields SHOULD be added to any message which is reintroduced by a
user into the transport system. A separate set of resent fields SHOULD be
added if this occurs multiple time.... [and much else]"
Surely, that covers mailing list expansion precisely? The message comes
through the transport system to the list server. The list server looks at
it, takes it apart, decides what to do with it, and then puts it back into
the transport system with a new load of recipients, but in a form which
still makes it appear to each ultimate recipient that it came from the
original originator, with the original message-id, and that replies should
go back to him (modulo any Reply-To address). The fact that the "user" is
a bot is neither here nor there. We are used to the idea that "users" on
the internet are often bots.
Please have a look at the DRUMS wording, and tell me where I have
misinterpreted it. And if it doesn't mean that, then what ARE Resent
fields meant to be used for? Or is this another bug I have found in DRUMS
:-( .
Looking at what happens in the real world, I see that this list (expanded
by Majordomo, I believe) does NOT add Resent fields, but the usenet-format
list (expanded by Listserv, I believe) DOES. So the real world is clearly
confused on this issue.
And if the expander is not supposed to add Resent fields, what is it
supposed to add? It needs something to show it has been involved (and to
detect those loops at the same time).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5