> > 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
writing to your :include: alias for your list, there is NOTHING
do about it. Your MTA is not passing control of the message to
handling the distribution itself. Fix this hole in your MTA. Majordomo
not announce the :include: address in any of the message headers
also happens from a misconfigured MTA. (Unless a list owner
"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.
sees the mail that the MTA passes to it. Majordomo does not create a
follow-up address either. This is done by a human making modifications
.config file for their list, or a human that made a global change to the
> > 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
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
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
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
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
reply-to address correctly, mail would not come back to the list
that is a different religious discussion.