[vchkpw] SOLVED: Re: [vchkpw] Re: Request for new feature: Internal-only accounts
Inter7 launched eMPF. Was eMPF inspired by this thread? Regards, bnegrao
Re: [vchkpw] SOLVED: Re: [vchkpw] Re: Request for new feature: Internal-only accounts
On Wednesday 29 June 2005 10:05 am, Bruno Negrão wrote: Inter7 launched eMPF. Was eMPF inspired by this thread? Partly from this thread. And partly from Sarbanes-Oxley requirements. Ken Jones
[vchkpw] Re: REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Guys, I'd like to know where the vmoduser command stores its information about which user can relay or cannot. To proceed with my idea of internal-only accounts, I'm thinking about using this database as my internal-only users list for the program I'll run using the QMAILQUEUE patch. bnegrao. 'vmoduser -rs' will disable relay *AND* disable SMTP-AUTH ability for given e-mail-address, so even if they set up their MUA to do SMTP-AUTH they'll not be allowed and therefore not gain RELAYCLIENT-privileges.
Re: [vchkpw] Re: REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Bruno Negro wrote: Guys, I'd like to know where the vmoduser command stores its information about which user can relay or cannot. To proceed with my idea of internal-only accounts, I'm thinking about using this database as my internal-only users list for the program I'll run using the QMAILQUEUE patch. Hi, It stores that information in the GID field of the vpasswd file (or gid field in *sql) Regards, Rick
Re: [vchkpw] Re: Request for new feature: Internal-only accounts
On Tuesday 14 June 2005 20:44, Peter Palmreuther wrote: Maybe because of easier mail user management and the lack of necessity to create a system user ID for every mail recipient?! Well, I suppose it's a matter of opinion, but I find it easier to manage system users (who need not be able to log in) on a dedicated mail server than to deal with the complexities of vpopmail. A single interface to manage either style could be made easily enough. I'm not quite sure why you add the '?!' on there, because an entry in /etc/passwd is less complex than an entry in /var/vpopmail/domain/whatever/vpasswd, certainly not moreso! I will admit though that vpopmail does offer more features that you might care about - I just don't happen to use any of them. Sure. I interpreted 'external' as 'not my server', not 'outside this particular domain' ... a limitation I included silently one should in fact be aware of. Okay. :) My perspective is a bit different because I was thinking about it from my perspective, which would be providing external hosting of e-mail for a client, as that's what we do. If somebody called me up and said they wanted mails not to go to external addresses, I would assume that they meant they wanted to keep mail within their domain - none of the other domains on that server! Cheers, -- Casey Allen Shobe | http://casey.shobe.info [EMAIL PROTECTED] | cell 425-443-4653 AIM Yahoo: SomeLinuxGuy | ICQ: 1494523 SeattleServer.com, Inc. | http://www.seattleserver.com
[vchkpw] Re: Request for new feature: Internal-only accounts
Hello Casey, On Wednesday, June 15, 2005 at 9:08:38 AM Casey wrote: On Tuesday 14 June 2005 20:44, Peter Palmreuther wrote: Maybe because of easier mail user management and the lack of necessity to create a system user ID for every mail recipient?! Well, I suppose it's a matter of opinion, but I find it easier to manage system users (who need not be able to log in) on a dedicated mail server than to deal with the complexities of vpopmail. A single interface to manage either style could be made easily enough. Guess I made myself not clear. 'mail user management' was meant for 'e-mail only users' only! Even with only one e-mail-domain I find it easier to maintain these users e.g. using 'qmailadmin' than to maintain '/etc/passwd' entries. I'm not quite sure why you add the '?!' on there, because an entry in /etc/passwd is less complex than an entry in /var/vpopmail/domain/whatever/vpasswd, certainly not moreso! I added '?!' because you wondered about why somebody would want to use vpopmail for only a single domain and I can not answer this question for everybody else. So '?' meant to say: Maybe somebody has different reasons for doing this? and '!' was intended to express: This is the reason why I do install vpopmail even on single-domain servers! :-) -- Best regards Peter Palmreuther The only difference between a rut and a grave is their dimensions.
Re: [vchkpw] Re: REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Hi Peter, Let me see if I understood your plan. You say that, in order to disable the RELAYCLIENT to just some accounts, and this way, setting them as partially** internal-only, I should: ** remember that just by disabling the RELAYCLIENT variable the account could still receive external e-mail. They just can't send e-mail to external accounts. If so, this configuration still doesn't fully implement the internal-only accounts feature I'm looking for 1 - Disable the pop-before-smtp scheme by recompiling vpopmail. ( OR disable it just to a specific domain by running vmoduser -r domainname. ), AND Remove the RELAYCLIENT variable for the whole network, AND Enable the SMTP-AUTH scheme on the qmail server, AND configure full accounts (not internal-only) to authenticate via SMTP-AUTH. OR 2 - Enable the pop-before-smtp scheme for everybody in the domain, AND Remove the RELAYCLIENT variable for the whole network, AND selectively disable the pop-before-smtp capability of the internal-only accounts by running a vmoduser -r [EMAIL PROTECTED] for each internal-only account. Is this what you planned? I agree that both strategies are much better than putting a lot of IP addresses in the beginning of tcp.smtp file, and I also agree that just by disabling a user from sending e-mail to external accounts will force him to not use his work e-mail to contact his external friends, once he'll never be able the answer their messages. But there's a possibility for him to receive external e-mail, and I don't want this leak opened. So this is not what I'm looking for yet. More ideas? regards, - Bruno Negrao - Network Manager Engepel Teleinformática. 55-31-34812311 Belo Horizonte, MG, Brazil
[vchkpw] Re: REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Hello Bruno,
On Tuesday, June 14, 2005 at 2:29:58 PM Bruno wrote:
Let me see if I understood your plan. You say that, in order to disable the
RELAYCLIENT to just some accounts, and this way, setting them as
partially** internal-only, I should:
1 - Disable the pop-before-smtp scheme by recompiling vpopmail.
( OR disable it just to a specific domain by
running vmoduser -r domainname. ),
AND Remove the RELAYCLIENT variable for the whole network,
AND Enable the SMTP-AUTH scheme on the qmail server,
AND configure full accounts (not internal-only) to authenticate via
SMTP-AUTH.
Correct.
Is this what you planned?
Yes. As it was rather late yesterday when I wrote my mail I wasn't
100% concentrated. Sorry.
'vmoduser -r' will disable 'open_relay()'-calling when these users
authenticate via POP3 or IMAP. This way they wont end up in
'tcp.smtp.cdb' and RELAYCLIENT will not be set next time they
SMTP-connect.
'vmoduser -rs' will disable relay *AND* disable SMTP-AUTH ability for
given e-mail-address, so even if they set up their MUA to do SMTP-AUTH
they'll not be allowed and therefore not gain RELAYCLIENT-privileges.
Only problem left: external *incoming* mail ... as far as I can see
there's no ready to use solution build into vpopmail; you'd have to
create '.qmail-*' files for every no external mail allowed that call
a script which checks if mail is sent from external.
This can for sure be made dynamic and used by creating a template
.qmail and (sym)linking the other .qmail files against it, so a
change affects all at the same time.
The script checking for external incoming can e.g. inspect
$ENV{SENDER} for internal domain and if not 'exit(100)' to bounce
the message. If the mail is internal simply 'exit(0)' and have
|vdelivermail '' bounce-no-mailbox in .qmail file.
--
Best regards
Peter Palmreuther
The end move in politics is always to pick up a gun. - Buckminster
Fuller
[vchkpw] Re: Request for new feature: Internal-only accounts
On Tuesday 14 June 2005 17:04, Peter Palmreuther wrote: 'vmoduser -rs' will disable relay *AND* disable SMTP-AUTH ability for given e-mail-address, so even if they set up their MUA to do SMTP-AUTH they'll not be allowed and therefore not gain RELAYCLIENT-privileges. Keep in mind though, that this is not really a valid solution unless you host only one domain on the mail server, in which case I have to wonder why you run vpopmail at all. If joe.com and bob.com are hosted on the same server, they'll be able to send each other mail even with the above measures. Cheers, -- Casey Allen Shobe | http://casey.shobe.info [EMAIL PROTECTED] | cell 425-443-4653 AIM Yahoo: SomeLinuxGuy | ICQ: 1494523 SeattleServer.com, Inc. | http://www.seattleserver.com
[vchkpw] Re: Request for new feature: Internal-only accounts
Hello Casey, On Tuesday, June 14, 2005 at 8:48:26 PM Casey wrote: 'vmoduser -rs' will disable relay *AND* disable SMTP-AUTH ability for given e-mail-address, so even if they set up their MUA to do SMTP-AUTH they'll not be allowed and therefore not gain RELAYCLIENT-privileges. Keep in mind though, that this is not really a valid solution unless you host only one domain on the mail server, in which case I have to wonder why you run vpopmail at all. Maybe because of easier mail user management and the lack of necessity to create a system user ID for every mail recipient?! If joe.com and bob.com are hosted on the same server, they'll be able to send each other mail even with the above measures. Sure. I interpreted 'external' as 'not my server', not 'outside this particular domain' ... a limitation I included silently one should in fact be aware of. -- Best regards Peter Palmreuther A woman is only a woman, but a good cigar is a smoke.
Re: [vchkpw] Re: REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Hi Peter,
'vmoduser -rs' will disable relay *AND* disable SMTP-AUTH ability for
given e-mail-address, so even if they set up their MUA to do SMTP-AUTH
they'll not be allowed and therefore not gain RELAYCLIENT-privileges.
when we use vmoduser command, where does it store the information of which user
can do what?
This can for sure be made dynamic and used by creating a template
.qmail and (sym)linking the other .qmail files against it, so a
change affects all at the same time.
The script checking for external incoming can e.g. inspect
$ENV{SENDER} for internal domain and if not 'exit(100)' to bounce
the message. If the mail is internal simply 'exit(0)' and have
|vdelivermail '' bounce-no-mailbox in .qmail file.
Did you read my idea(posted some messages ago) about making a script to be run
with QMAILQUEUE patch to filter all the passing messages?
With this idea we wouldn't even have that problem of the possibility of sending
e-mails from one local domain to other local domain - the program could block if
From: and To: are not on the same domain.
Can you comment about this idea?
-
Bruno Negrao - Network Manager
Engepel Teleinformática. 55-31-34812311
Belo Horizonte, MG, Brazil
[vchkpw] Re: REQUEST FOR NEW FEATURE: INTERNAL-ONLY ACCOUNTS
Hello Bruno, On Monday, June 13, 2005 at 9:22:50 PM Bruno wrote: Now, the director of one of the companies I give support asked me to set a bunch of e-mail accounts as internal-only, i.e., they can send e-mail internally but cannot send or receive external e-mails. vmoduser -r $ADDRESS At least 5.4.5 has this possibility. If you further enforce SMTP-AUTH for all SMTP-connections that need to relay (i.e.: don't set RELAYCLIENT for anything other than 127.0.0.1) and disable roaming users you should have gained what you're looking for. -- Best regards Peter Palmreuther hselF ruoY eM roF...luoS ruoY doG roF
