I now understand how using the @Filename feature of resend can help hide
your distribution alias from EXPN & VRFY queries. Even better is disabling
the EXPN and VRFY commands altogether. And to avoid attempts to exploit
commonly used identifiers, changing the distribution alias to
test-outgoing-secret obviously helps.
I don't have to worry about local users on the machine poking around local
files. Only administrators can login to the server itself. All mailing list
users are remote. Since that's the case, is using the "security through
obscurity" approach above sufficient? Are there any other methods people
could use to discover my test-outgoing-secret alias?
As for the use of virtusertable, I get the impression that the idea was
based on sendmail handling e-mail differently depending on the arrival
vector. Messages being delivered via port 25 would run into the
"test-outgoing-secret@foo.com error:nouser User Unknown" error; whereas,
local e-mail passed from a program (like resend) would still work thanks to
the /etc/mail/majordomo.aliases entry for the test-outgoing-secret include
file.
Despite following the majordomo FAQ 3.6 (Matt Perry section) in combination
with the sendmail virtual hosting page
(http://www.sendmail.org/virtual-hosting.html) I can't get it to work
properly. It seems to be an all-or-nothing proposition. I can get the
virtusertable to respond with the error:nouser message when telnetting to
port 25 and trying to send directly to the distribution alias:
553 5.3.0 test-outgoing-secret@host.company.com... User Unknownabout
But this setup also breaks my authorized user attempts at posting via the
usual test-list address. The following is what ended up in my list-owner's
mailbox:
[SNIP]
----- The following addresses had permanent fatal errors -----
test-outgoing-secret
(reason: 553 5.3.0 <test-outgoing-secret@host.mycompay.com>... User
Unknownabout)
(expanded from: test-outgoing-secret)
----- Transcript of session follows -----
... while talking to localhost.mycompany.com.:
>>> DATA
<<< 553 5.3.0 <test-outgoing-secret@host.mycompany.com>... User Unknownabout
550 5.1.1 test-outgoing-secret... User unknown
[SNIP]
It's as if sendmail no longer treats the delivery vector differently.(?)
Perhaps this is due to the new approach with sendmail 8.12 using sendmail.cf
and submit.cf. Or perhaps I've completely misunderstood how to setup the
virtusertable stuff and sendmail will still work as it always has if I get
it right.
Has anyone gotten the virtusertable approach to restricting posts working
with sendmail 8.12.6?
Thanks again,
John C
-----Original Message-----
From: David Corlette [mailto:corlette@huarp.harvard.edu]
Sent: Thursday, September 05, 2002 2:55 PM
To: John Christian; majordomo-users@greatcircle.com
Subject: Re: restricing posts to authorized users leaves open
backdoor?
> Hi majordomo gurus,
>
> I'm configuring a mailing list that only allows 1 person to send periodic
> announcements to ~5,000 subscribers. The list is open to folks subscribing
> and un-subscribing themselves, but only the authorized user(s) can send
> messages to the list. I'm using a few local accounts on my server as the
> test subscribers and authorized user.
--SNIP---
This is covered in the FAQ:
http://www.greatcircle.com/majordomo/majordomo-faq.html#3.6
We used the "obscurity" method you mention on our old lists, i.e. out
outgoing addresses were "listname-<random number>", but, as
mentioned, this is reported in the Received: headers. We considered
hiding this using the method in the FAQ, but eventually we came up
with the idea of using the "virtual hosts" feature of sendmail to
take care of it. In other words, we have sendmail add a suffix to
all incoming mail for a particular host, then in our alias files the
"public" aliases have that suffix, the non-public ones do not. Works
pretty well.
Dave C
---------------------------------------------------------
David Corlette mailto:corlette@huarp.harvard.edu
(617)495-5922 http://www-arp.harvard.edu
|
|
