Restricting sending mail to domain or group
Hi folks,
has anybody a simple solution for the following request?
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com. (2) - rather optional: refine the restrictions, e.g. two groups, grp1@company.com and grp2@company.com. Grp1 members should be able to send mails to grp2 but not vice versa.
What else than sieve would keep dealing with that demands as simple as possible?
Thanks in advance and sorry for abusing this list for this kind of „problem“ which is not a bug.
Regards, -M
Can the groups send and receive from outside the domain ? If so, it's going to be difficult to prevent groups from seeing each others emails because an email that originated from group A could be sent to some other domain (out on the internet), then get forwarded to a user in group B. Just a thought.
On Wed, 2018-12-05 at 18:57 +0100, admin wrote:
Hi folks,
has anybody a simple solution for the following request?
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com. (2) - rather optional: refine the restrictions, e.g. two groups, grp1@company.com and grp2@company.com. Grp1 members should be able to send mails to grp2 but not vice versa.
What else than sieve would keep dealing with that demands as simple as possible?
Thanks in advance and sorry for abusing this list for this kind of „problem“ which is not a bug.
Regards, -M
Yes, all members are full accounts being able to send and receive inside and outside.
Technically I need an account/alias that is only able to receive mails from a defined subset of users.
Ideally there is an approach which saves me from caring for several lists of redudant data.
Am Mittwoch, den 05.12.2018, 13:09 -0500 schrieb John Tulp:
Can the groups send and receive from outside the domain ? If so, it's going to be difficult to prevent groups from seeing each others emails because an email that originated from group A could be sent to some other domain (out on the internet), then get forwarded to a user in group B. Just a thought.
On Wed, 2018-12-05 at 18:57 +0100, admin wrote:
Hi folks,
has anybody a simple solution for the following request?
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com. (2) - rather optional: refine the restrictions, e.g. two groups, grp1@company.com and grp2@company.com. Grp1 members should be able to send mails to grp2 but not vice versa.
What else than sieve would keep dealing with that demands as simple as possible?
Thanks in advance and sorry for abusing this list for this kind of „problem“ which is not a bug.
Regards, -M
-- awib IT Solutions Manuel Knitza info@awib.it +49 (0) 7531 804 55 11
Am 05.12.2018 um 18:57 schrieb admin:
Hi folks,
has anybody a simple solution for the following request?
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com. (2) - rather optional: refine the restrictions, e.g. two groups, grp1@company.com and grp2@company.com. Grp1 members should be able to send mails to grp2 but not vice versa.
Both to be setup on MTA side.
What else than sieve would keep dealing with that demands as simple as possible?
Thanks in advance and sorry for abusing this list for this kind of „problem“ which is not a bug.
Regards, -M
Alexander
On Wed, 5 Dec 2018, Alexander Dalloz wrote:
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com. (2) - rather optional: refine the restrictions, e.g. two groups, grp1@company.com and grp2@company.com. Grp1 members should be able to send mails to grp2 but not vice versa.
Both to be setup on MTA side.
Agreed. You can manage your mailing lists with software (e.g. mailman), or hack in a filter between the (public) external and (secret) internal mailing list e.g.
# Forwards to grp1-secret@ if sender is approved
grp1: |/path/to/check-sender-filter
grp1-secret: :include:/path/to/grp1.listIf spoofing is a concern, you'll have to endow your filter with more intelligence.
Joseph Tam jtam.home@gmail.com
Am Mittwoch, den 05.12.2018, 13:46 -0800 schrieb Joseph Tam:
On Wed, 5 Dec 2018, Alexander Dalloz wrote:
[...]
Both to be setup on MTA side.
Agreed. You can manage your mailing lists with software (e.g. mailman), Actually I tried to avoid introducing another system...
As for now round about 5 people would gain permission to send to this all alias. We could use mailchimp, as this is already part of marketing dpt. but I really would like to keep this very simple.
Following possibilities so far:
(1) Either I take care of having a network shared text file with all emplpyees up to date (2) Using/introducing a mailing list (mailman // mailchimp) (3) via postfix smtpd_sender_restrictions smtpd_receiver_restrictions? I am not sure if this is really possible (4) I could setup an internal virtual domain, e.g. vcomapny.com and restrict this domain to only be able to receive mails from @company.com and setup all@vcompany.com group alias. (5) setup domain wide sieve to only accept mail from all@company.com if sender i eieth a, b, or c...
So far (4) and (5) seem to be easy to implement. For me more or less the same overhead with (1) but for the user much simpler.
In this case simplicity has priority over giving birth to a feature that has already an app for to be used with.
or hack in a filter between the (public) external and (secret) internal mailing list e.g.
# Forwards to grp1-secret@ if sender is approved grp1: |/path/to/check-sender-filter grp1-secret: :include:/path/to/grp1.listThanks!
If spoofing is a concern, you'll have to endow your filter with more intelligence.
Its not.
Joseph Tam jtam.home@gmail.com
-M
On 12/05/2018 06:57 PM, admin (@awib.it) wrote:
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com.
Do you have a means to identify "some suitable account was used" - as opposed to a trivially forged sender address - *other* than by watching the actual MUA-to-MSA login happen? (E.g., you might impose a requirement that such e-mails be cryptographically *signed* - per S/MIME, DKIM, or whatever method can be verified automatically later on. Or your MSA might not accept e-mail from outside the LAN and you can globally assign trust to all e-mails that come from it.)
If not, then grabbing that info on the MSA and somehow forwarding it securely to all@'s final MTA / MDA to base the filtering on is the best you can do. (And ideally, your organization's MSA and MDA reside within one and the same MTA and you'll have a filtering config/API where you already can evaluate *both* parts of the input information - sending account and that it's to be delivered to all@ - at once.)
Regards,
Jochen Bern Systemingenieur
www.binect.de www.facebook.de/binect
Am Mittwoch, den 05.12.2018, 22:31 +0000 schrieb Jochen Bern:
On 12/05/2018 06:57 PM, admin (@awib.it) wrote:
I have a group alias (all@company.com). (1) Only company.com accounts should be able to send an email to everybody in that company via all@company.com.
Do you have a means to identify "some suitable account was used" - as opposed to a trivially forged sender address - *other* than by watching the actual MUA-to-MSA login happen?
Either way would suffice - the simpler the better.
Restricting the sender to be on the same domain if mail is sent to the company group alias would be fine.
All I try to achieve is to protect those in the group from unwanted "SPAM", so no one from outside the domain should be able to send to that alias (all@company.com is quite generic...). Optionally only chosen senders (whitelist) should be able to send to that alias. We do not want our mail system to become a craigslist or everbody being able to reach thousdands of people with only one email being sent.
We are rather generous thinking of mail attachments (up to 100MB). I do not want to see an email like this copied over to thousands of accounts...
[...]
Regards,
Thanks four your thoughts!
-M
participants (5)
-
admin
-
Alexander Dalloz
-
Jochen Bern
-
John Tulp
-
Joseph Tam