What are ways, that an email can be shared for software collaboration?

[sidetone]

What are ways which an email account can be shared, for software collaboration?

Emailing lists, may be one way, which have a receiving email account, and an email to there, goes to everyone on that list.

Also, I've wondered about shared email accounts, but I don't know much about them. Where everyone has their own password, or perhaps returns an email from different accounts. Though, everyone gets an email to an account. Perhaps emails to that account are forwarded to members who are associated with that account?

Purposes could be for, when a single email address can be for a group of maintainers, rather than one. In one case, I've seen this on the emailing lists, where a maintainer address goes to an email list, and everyone there receives it.

If there's anything to add, for more software related collaboration purposes, or how shared email accounts work, I'm curious.

 

[freezmi]

Hello!

not sure if this is what you're looking for, but there is an IMAP feature called 'shared folder' / 'public folder' or 'shared namespace'.
one mail comes from a mailinglist to a virtual account on mail server that has IMAP service, the mail gets placed into a Maildir that is readable by all users (this is the 'shared folder'). the users of that server can 'subscribe' and 'unsubscribe' to such 'shared folders' via the mail client, can read those mails and the mail 'read/unread' characteristic is tracked for each user individually by the IMAP server.

I use such a setup using postfix that places mails from mailing lists into world-readable Maildirs via the mail/aliases config file and then dovecot that provides that Maildir in a 'shared namespace'. the users can use any Mail User Agent - anything from thunderbird to mutt. this setup is great for multiple developers to casually read mails from different mailing lists without the need for them to actually subscribe with their private email address. it's great for providing an 'archival view' right in their email client. however in most cases they will not be able to reply to those mailing lists since their personal address is not recognized.

 

[sidetone]

an IMAP feature called 'shared folder' / 'public folder' or 'shared namespace'. one mail comes from a mailinglist to a virtual account on mail server that has IMAP service, the mail gets placed into a Maildir that is readable by all users (this is the 'shared folder'). the users of that server can 'subscribe' and 'unsubscribe'

users can use any Mail User Agent - anything from thunderbird to mutt.

That's good information.

I had in mind, that maintainers of ports are treated as 1 person per email address. Some go to the mailing list, which have their own, including that of ports @freebsd.org, Xorg, kde, Python, Ruby. However, some are organizations which are outside of the FreeBSD mailing lists. Since all the maintainership process only cares about the email address, why not encourage shared email addresses to take care of individual ports at a time, based on Port theme. A group of people would act as one email address as a single unit of port maintainer to address many individual ports based on a theme, like category or type of port.

I read that there are shared emails, where multiple users can send email from that account, as well as receive it. It's something like what you said, but with more abilities. I'm curious of the other ways in which emails can be shared, from what you wrote, about one with more features, and about email lists that are independent of FreeBSD's mailing lists, which could act as a maintainer/maintainer group using 1 email.

 

[richardtoohey2]

I read that there are shared emails, where multiple users can send email from that account, as well as receive it. It's something like what you said, but with more abilities.

Isn't this just IMAP and a shared email address/password?

I work with other people and we set up support@somecompany.com. (But it could be developers@someproject.com) We set that up with IMAP, and we all have the same login details.

We can all see the emails that arrive into that account, and we can all send emails from that account (as support@somecompany.com.)

Are you after something else? I don't see what exactly you are after?

 

[sidetone]

Isn't this just IMAP and a shared email address/password?

I work with other people and we set up support@somecompany.com. (But it could be developers@someproject.com) We set that up with IMAP, and we all have the same login details.

We can all see the emails that arrive into that account, and we can all send emails from that account (as support@somecompany.com.)

I read there was one, where everyone had different passwords to the same account. It was very close to what you described with that exception. Everyone has the same accountability of that email address, with the exception of a different password for each person to that account. What you wrote is one solution though. If I understood correctly, I understood your words as a single password for many users of that email.

Are you after something else? I don't see what exactly you are after?

I'm trying to understand what different types of emails there are: typical email addresses, mailing lists which receive to an email address, and if there are more types of shared email addresses.

 

[richardtoohey2]

I read there was one, where everyone had different passwords to the same account. It was very close to what you described with that exception. That's one solution though. If I understood correctly, I understood your words as a single password for many users of that email.

Yes, the big disadvantage of the shared password IMAP account is that if someone sends a "bad" email from the shared email account it's not obvious which (or is that whom?) of the people with the login did the deed.

 

[sidetone]

I'm thinking that everyone has to be trusted enough to share that account, and it would be treated as one. But I want different passwords for each user, so that one user doesn't reset it on accident and lock everyone else out, unless it's the main user of that account, who is the administrator. Maybe there's a way, that what you say works, and only the admin or on user can change the password.

I need to look this up, from what I found on the internet, and see the different options of shared accounts or types of non traditional accounts.

 

[cy@]

You could share an account. At $JOB we use M$ Outlook. Our group uses a shared mailbox. A shared mailbox is like its own email account all members of the team have access to. We can all read email in the shared mailbox and we can all send emails (i.e. reply) using the shared mailbox's email address.

And yes, everyone in the team is trusted to use the shared mailbox responsibly. If you're doing collaborative software development and use the shared mailbox for users to send the team, for example trouble tickets, someone in the team would reply. How you use the shared mailbox would be something your team would have to work out amongst yourselves.

Of course how you set this up depends on what software each of you is using. Different people in your team might use different software. That is less important than what you as a team (people) decide on how shared mailbox workflow works (within your team). That's the first thing you need to work out. The rest (software) will be relatively easy compared to the people part of the equation.

 

[freezmi]

I'm thinking that everyone has to be trusted enough to share that account, and it would be treated as one. But I want different passwords for each user, so that one user doesn't reset it on accident and lok everyone else out, unless it's the main user of that account, who is the administrator. Maybe there's a way, that what you say works, and only the admin or on user can change the password.

I need to look this up, from what I found on the internet, and see the different options of shared accounts or types of non traditional accounts.

you can have multiple users (each with their own set of credentials) that share a public folder. each user will have it's own index containing which message was read. this is the entire idea of the 'shared namespace' I talked above.
if you want I can give you IMAP access to a server of mine and you can see how it looks.

the added complexity that you require is that maintainers should use a custom 'From:' header depending on which shared folder they happen to reply to. I see this work only if you forget about shared namespaces (since those only cover the mail retrieval part of the equation and not the sending part) and simply create mail accounts for each maintainer group. at least on dovecot you can have multiple sets of credentials for the same mailbox.

not sure how you want to handle maintainers that do not have a freebsd mail account tho.
I see freebsd.org has at least SPF set up (which is a good thing), so people sending mails with a 'From: something@freebsd.org' header and that not use one of those two IPs defined in _spf.freeebsd.org as SMTP servers will end up marked as spam.

# dig +short TXT freebsd.org
[..]
"v=spf1 redirect=_spf.freebsd.org"

# dig +short TXT _spf.freebsd.org
"v=spf1 ip4:96.47.72.81 ip6:2610:1c1:1:606c::19:2 ~all"

 

[freezmi]

also, if these mails that the maintainers get are all bug-related, one might consider the Bugzilla inbound email interface.

a script could parse incoming mails and auto-complete
@product ProductName
@component ComponentName
based on the mail headers and create a new message that automatically gets added into bugzilla, maintainers are messaged, all discussions are archived in bugzilla.

this would need some virtual accounts like sysutils-team@freebsd.org, math-team@, games-team@, that all get delivered to a maildir where a script-filter adds some metadata to the message and passes it to bugzilla's email_in.pl

but this has a lot of moving parts, might pollute bugzilla and might become a headache later on

 

[sidetone]

I use such a setup using postfix that places mails from mailing lists into world-readable Maildirs via the mail/aliases config file and then dovecot that provides that Maildir in a 'shared namespace'. the users can use any Mail User Agent - anything from thunderbird to mutt.

. at least on dovecot you can have multiple sets of credentials for the same mailbox.

This must be one way for a setup, for which I've read about. Dovecot uses ACL for access control, which I'm unfamiliar with. I'm used to the typical rxw 3 digits each adding up to 7.

if you want I can give you IMAP access to a server of mine and you can see how it looks.

That's ok, bc I wouldn't be able to get around to it. I can understand explanations and examples. Thank you though.

This is great information, and from me, it would take a paid service, bc these setups would take a few months for me to learn, with a fresh mind. Years with my tired mind.

a custom 'From:' header depending on which shared folder they happen to reply to.

I see this work only if...

That would be nice, but not necessarily required. That would allow some accountability of who sent the email from the single shared account. If it were made into a setting which couldn't be customly changed by each user, and it be a part of the individual credential and part of the email software.

also, if these mails that the maintainers get are all bug-related, one might consider the Bugzilla inbound email interface.

This reminds me of two things: email lists, which have been mentioned above, and of how PHP with HTML allows emails to be sent from a webpage. Doesn't have to be PHP, could be Ruby or that Bugzilla Perl interface example.

Receiving for multiple people is easier, including the unmentioned forwarding. Sending is more complicated. Seeing how a webpage can be used to send an email from a single account, multiple users with access to that page, can send email as 1 group account.

So, I understand 4 ways:

• Traditional email
• Shared email, which includes a overly simple set up, or a technology like Dovecot which allows better access control, which is preferred
• Mailing lists
• A software web/internet interface accessible by multiple users, which uses 1 email address, that all users don't necessarily need access to

 

[freezmi]

This is great information, and from me, it would take a paid service, bc these setups would take a few months for me to learn, with a fresh mind. Years with my tired mind.

Above I used postfix, dovecot, mutt, thunderbird just as examples (that I happen to use), they can be replaced by other MTA/MUA/MDA/LDA software that follow the RFCs.

I can try to help you with a proof-of-concept if you want, free of charge. I have a lot of free time and I'd be delighted to help out. I did such setups in the past and a refresher would be welcome. All I would need is a set of specifications that include what services currently exist, how they are tied together and what features the target solution should provide.

 

[zirias@]

First decide about the intended collaboration model. If you prefer "open, public discussion", a mailing list will serve that well. That's IMHO very suitable for open-source development. If, on the other hand, you want a SPOC (single point of contact) with some opaque "team" inside behind that, look for shared mailboxes. That's IMHO suitable for closed-source and/or commercial software.

When you decided for one of these, look for the software you need. For a mailing list software, you probably want features like good handling of bounces, ARC, public web archives, etc. For a shared mailbox, you want some IMAP server giving access to the same mailbox to different users (with their personal credentials).

 

[6502]

Email forwarding - one common email forwards copies to personal addresses of all "subscribers". Then Reply-To email can be the common address.