Christian, [27.07.17 14:40]
So, to conclude: We'll have multiple identities per account consiting of:

• email address
• name
• signature
• gpg-key in the future

Christian, [27.07.17 14:41]
and no transport mechanism

Christian, [27.07.17 14:41]
By default email-address can be anything, for known services we can remove it entirely where it isn't supported at all.

Christian, [27.07.17 14:42]
For some services we may want to support only changing the reply-to but not the from (e.g. kolabnow)

Michael Bohlender, [27.07.17 14:42]
But we won't stop someone volunteering to do it with transport?

Christian, [27.07.17 14:42]
We likely will, at least for now.

Christian, [27.07.17 14:42]
If you want a transport, setup an account for it.

Michael Bohlender, [27.07.17 14:43]
alright

Christian, [27.07.17 14:44]
(that assesment might of course change if we have a compelling usecase for it, but right now I don't think the additional complexity would be worth it)

FWIW, mailinglists are a case where just chaning the reply-to address likely doesn't suffice (the email will be bounced for subscribers only lists I think).

One drawback of setting up different accounts when you really want to use multiple mail-accounts through one is that the sent mail ends up in the accounts sent folder, which means it will also only show up there in the conversation.

So that would mean that if your email provider doesn't allow sending with other FROM addresses with the same transport then we just deem that setup broken, and otherwise everything works as it should.

This adds no additional value until we have signatures, gpg-key or have a service that supports sending with additional email addresses.