mp@gtt-technologies.de wrote:
>
> John,
> > If one of the members of the mailing list has a virus, and the mailing list
> > is configured to only allow posting from members of the list, then the virus
> > has full access to send mail to the list and have it be accepted and
> > processed.
> The problem with the mentioned list address is, that not only subscribers to the list
> are able to access it, but anyone. We tested it. But our actual list-configuration
> should allow only one person to send mails to the subscribers of the list.
Double and triple check your configuration. If spammers, viruses, or
lamers are
writing to your :include: alias for your list, there is NOTHING
majordomo can
do about it. Your MTA is not passing control of the message to
majordomo, but
handling the distribution itself. Fix this hole in your MTA. Majordomo
does
not announce the :include: address in any of the message headers
either. This
also happens from a misconfigured MTA. (Unless a list owner
misconfigured the
"reply_to" setting in the listname.config file.)
Please show us your restrict_post and reply_to settings for your list.
>
> > However, this is not a problem for majordomo. This is a problem for
> > the mail systems on both the client machines and the the server that
> > has majordomo on it.
> We think that it is a problem of Majordomo, because Majordomo creates and
> configures the follow-up address in sendmail. It should by default implement the
> same access rights and restrictions as for the original address for access of
> Majordomo itself.
You keep talking like majordomo has any control over your mail.
Majordomo only
sees the mail that the MTA passes to it. Majordomo does not create a
"default"
follow-up address either. This is done by a human making modifications
to the
.config file for their list, or a human that made a global change to the
parse_
config.pl file.
>
> > If the client had virus protection systems in place, they would not
> > get the virus.
> Well, the very most of the servers, our subscribers are attached to, use virus filters.
> That was one of the problems, because each one, that was fooled by the false
> address of the virus mail, sent a "virus detected" notification "back" to the list.
> Because there was no default user restriction to that address, these notifications
> were sent to all subscribers.
>
> > To be even more filtering, you can put sendmail filters to block executables.
> > Or if you are list owner, you can create taboo descriptions which block
> > executable attachments.
> As I mentioned: the problem is not the filtering of executables, but the rights for
> accessing the mail address. Majordomo doesn't configure it properly. If an extern
> user would be refused to use this follow-up list address, no one would have to think
> about executable and spam filters. If you know a way to configure it this way, I
> would be delighted, if you'd could tell me. We were not able to find a satisfying
> solution for it by now.
As "I" mentioned, it is not up to majordomo, nor is it within majordomo
control,
to grant access to messages that do not touch majordomo. Here is the
example I am
trying to get across:
You have an MTA with no majordomo installed. You create an aliase with
a :include:
statement. The file that include points to has 5000 names/addresses in
it. When a
message comes into your MTA addressed to that alias, it will be
distributed by your
MTA to those 5000 addresses. Where is this a hole in majordomo? It's
not even
installed.
Now, even if you install majordomo, it does not create aliases for you.
It does not
insert any reply-to header in distributed messages, and it does not
accept messages
for distribution larger than 40K. The "restrict_post" setting is
exactly for refusing
mail from anyone that does not match an address on the membership list,
or other file
containing email addresses, but addresses can be forged. If you set the
follow-up or
reply-to address correctly, mail would not come back to the list
automatically, but
that is a different religious discussion.
Dan Liston
Follow-Ups:
References:
|
|
