Hmm... another, somewhat related issue - it seems that only mails addressed to System Email Address * are handled and all other are ignored. Would it be possible to handle all incomming emails that end up in the particular mailbox?

Check service desk setting of a project, you can customized the address send to a particular project.

But in there you have only Service Desk Name with the comment "Service desk name can be used to construct service desk email address of current project, which takes the form +@. Issues can be created in this project by sending email to this address"

Thus at best the email for the whole deployment is always the same (e.g. [email protected]) but it can vary by subaddressing. What I try to to is to get 1dev to handle various, different localparts (e.g. [email protected], [email protected] and [email protected])

This adds extra complexity of the setup. Why not just tell your customer to only send service email to a single address (or project specific email address)?

Because we exist for a long time, have a number of customers and over the course of history we used 2-3 emails and we have to (should) support a couple of them.

I'm not sure that at the basic removing requirement for System Email Address * (so that all emails from the inbox would be handled) would increase significantly complexity.

System email address is still required, as otherwise OneDev does not know which address to be used as sender address.

System email address is still required, as otherwise OneDev does not know which address to be used as sender address.

Agreed, but could it be renamed/repurposed as "Sender email" only?

System email address is particularly phrased as such as it services not only sender address, but also target address for all incoming emails.

Also as I mentioned, OneDev has mechanisms to create issues in different projects, either via plus addressing, or by checking sender address if target address does not include project info.

Adding another mechanism to create issues in different projects based on target email address itselt just complicates things and causes confusions. I'd suggest to forward the emails at your mail server side to project specific addresses as necessary for this historical reason.

System email address is particularly phrased as such as it services not only sender address, but also target address for all incoming emails.

From what I understand 1dev relies heavily on subaddressing (custom projects, replies to issues, etc). Wouldn't it be possible to just ignore what localpart is and just use subaddress part?

Adding another mechanism to create issues in different projects based on target email address itselt just complicates things and causes confusions. I'd suggest to forward the emails at your mail server side to project specific addresses as necessary for this historical reason.

Again: I given up on setting up issues in different project at this point in our conversation. What I'm asking is just for parsing/handling all incoming emails from mailbox (instead of filtering by configured email). If the mail matches the configured address/subaddressing then fine, do the additional filtering but don't drop incoming emails processing if it doesn't match configure email - just process it with default configuration and put it in default project.

Right now we don't do forwarding - we simply have a couple of aliased localparts to one mailbox so setting up forwarding to subaddress address would be somewhat convoluted and inefficient (maintaining multiple mailboxes)

mailbox so setting up forwarding to subaddress address would be somewhat convoluted and inefficient (maintaining multiple mailboxes)

The mailbox you already have is for sales and support. Then you make one additional mailbox for servicedesk. That new mailbox is managed by OneDev only.

In your existing mailbox you setup a forwarding rule without subaddresses and configure in OneDev what should happen for mails from sales and support. Shouldn't that work and be relatively easy to maintain because everything is setup in OneDev and the forwarding rule is static and never changes? At least it sounds like a fair workaround for now.

State changed as code fixing the issue is committed (9c94f36f)

State changed as build #4264 is successful

@wojtek this can now be achieved by turning off option only monitor system address in mail service of build #4264

@wojtek this can now be achieved by turning off option only monitor system address in mail service of build #4264

This sounds perfect! Thank you.