[Feature request] Issue reply by email #372

cornelius.roemer commented 2020年12月24日 15:37:07 +01:00

One nice Github/Gitlab feature that is missing from Gitea/Codeberg is reply to issue by email.

There's an upstream feature request for this at Gitea https://github.com/go-gitea/gitea/issues/9067 but I was wondering if this was something that could possibly be done just here - so I'll throw it in the ring.

One nice Github/Gitlab feature that is missing from Gitea/Codeberg is reply to issue by email. There's an upstream feature request for this at Gitea https://github.com/go-gitea/gitea/issues/9067 but I was wondering if this was something that could possibly be done just here - so I'll throw it in the ring.

6543 commented 2020年12月24日 16:14:20 +01:00

it could posible done by a "bot" who read mails & act for the user via API & sudo header

it could posible done by a "bot" who read mails & act for the user via API & sudo header

cornelius.roemer commented 2020年12月24日 16:31:56 +01:00

There's a WIP PR over at Gitea: https://github.com/go-gitea/gitea/pull/13585

There's a WIP PR over at Gitea: https://github.com/go-gitea/gitea/pull/13585

hw commented 2020年12月24日 22:18:08 +01:00

it could posible done by a "bot" who read mails & act for the user via API & sudo header

Considering the security/spam issues brought up in the PR discussion it's probably best to do contribute to the PR and have one centralized implementation that is easier to maintain?

> it could posible done by a "bot" who read mails & act for the user via API & sudo header Considering the security/spam issues brought up in the PR discussion it's probably best to do contribute to the PR and have one centralized implementation that is easier to maintain?

WhyNotHugo commented 2023年01月30日 11:10:28 +01:00

This is now implemented in gitea: https://github.com/go-gitea/gitea/pull/22056

However, the implementation seems a lot more complex than needed; gitea will pull emails via IMAP server, so aside from the SMTP server that receives email, an IMAP server is required to do the handoff, as well as proper storage to retain these mailboxes.

This is now implemented in gitea: https://github.com/go-gitea/gitea/pull/22056 However, the implementation seems a lot more complex than needed; gitea will pull emails via IMAP server, so aside from the SMTP server that receives email, an IMAP server is required to do the handoff, as well as proper storage to retain these mailboxes.

crystal commented 2023年01月31日 09:27:32 +01:00

What part of that seems more complex than needed? If you use POP3 to receive emails without IMAP, you still need to store them on the POP3 server until the client picks them up. I suppose Gitea could listen on port 25 but that's a whole can of worms that is probably best left to a proper SMTP server.

What part of that seems more complex than needed? If you use POP3 to receive emails without IMAP, you still need to store them on the POP3 server until the client picks them up. I suppose Gitea could listen on port 25 but that's a whole can of worms that is probably best left to a proper SMTP server.

WhyNotHugo commented 2023年01月31日 10:03:47 +01:00

The simplest and most obvious approach is for SMTP/LMTP to deliver webhooks (or equivalent) to gitea directly.

Adding IMAP into the mix is odd. IMAP is for a server to store email to later be polled by a potentially unreachable client, so that the client can later query the mailbox. It doesn't make sense when you're pushing messages between servers. And you still need an SMTP and LMTP to deliver into the IMAP mailbox.

I'm not sure why you suggest POP3, it also seems like over-complicating things.

The simplest and most obvious approach is for SMTP/LMTP to deliver webhooks (or equivalent) to gitea directly. Adding IMAP into the mix is odd. IMAP is for a server to store email to later be polled by a potentially unreachable client, so that the client can later query the mailbox. It doesn't make sense when you're pushing messages between servers. And you still need an SMTP and LMTP to deliver into the IMAP mailbox. I'm not sure why you suggest POP3, it also seems like over-complicating things.

crystal commented 2023年01月31日 10:18:13 +01:00

So you propose an API be added to Gitea to receive messages from an SMTP server in the form of a webhook? I've never seen an implementation like that. (削除) How do you configure the SMTP server to deliver the messages to that instead of a mailbox? (削除ここまで) Turns out Postfix can indeed be configured to pipe incoming messages to curl. Who knew?

I think the solution offered in Gitea is intended to be fairly easy to set up with an off-the-shelf mail account on whatever email serv(er|ice) you already have set up. As you mention, it does also have the advantage of still being able to collect messages if the Gitea server is down for some reason.

So you propose an API be added to Gitea to receive messages from an SMTP server in the form of a webhook? I've never seen an implementation like that. ~~How do you configure the SMTP server to deliver the messages to that instead of a mailbox?~~ Turns out Postfix can indeed be configured to pipe incoming messages to curl. Who knew? I think the solution offered in Gitea is intended to be fairly easy to set up with an off-the-shelf mail account on whatever email serv(er|ice) you already have set up. As you mention, it does also have the advantage of still being able to collect messages if the Gitea server is down for some reason.

WhyNotHugo commented 2023年01月31日 10:36:32 +01:00

Receiving via SMTP is what GitHub Enterprise does.

Receiving via LMTP is what Sourcehut does (although, to be fair, the SMTP server talks LMTP, which serves a similar role to "piping through curl).

SMTP servers keep the message around for 24/48hs if the destination is down, so if gitea/codeberg is down, they'd just retry delivery.

Receiving via SMTP is what GitHub Enterprise does. Receiving via LMTP is what Sourcehut does (although, to be fair, the SMTP server talks LMTP, which serves a similar role to "piping through curl). SMTP servers keep the message around for 24/48hs if the destination is down, so if gitea/codeberg is down, they'd just retry delivery.

crystal commented 2023年01月31日 13:20:33 +01:00

Outgoing servers do that, but would the incoming server keep the message and retry piping it to curl if the first request failed?

Honestly I don't think it would be all that difficult to support this with an extension of the existing code, so it could probably be implemented.

P.S. It appears the way Gitea implemented it is quite similar to GitLab :)

Outgoing servers do that, but would the incoming server keep the message and retry piping it to curl if the first request failed? Honestly I don't think it would be all that difficult to support this with an extension of the existing code, so it could probably be implemented. P.S. It appears the way Gitea implemented it is quite similar to [GitLab](https://docs.gitlab.com/ee/administration/incoming_email.html) :)

WhyNotHugo commented 2023年02月03日 10:46:46 +01:00

There's no real distinction "incoming server" vs "outgoing server". They're all SMTP and behave the same.

Say you send an email from example@posteo.de. Your MUA will send the email to your local SMTP (often this first bit is skipped in modern setups), which them relays it to posteo's SMTP, which then relays it to the recipients SMTP, which then delivers it to a mailbox via LMTP (e.g.: the final SMTP server hands off the email to the IMAP server via LMTP usually).

All of these SMTP servers behave the same: they keep retrying or bounce the message if they can't deliver within 48hs (or maybe it was 24hs?).

In this case, you'd be able to replace "deliver via LMTP to an IMAP mailbox" with "deliver via LMTP to something that sends webhooks". I suppose that "pipe via curl" is basically a less-standard way of doing LMTP, but should work all the same.

There's no real distinction "incoming server" vs "outgoing server". They're all SMTP and behave the same. Say you send an email from example@posteo.de. Your MUA will send the email to your local SMTP (often this first bit is skipped in modern setups), which them relays it to posteo's SMTP, which then relays it to the recipients SMTP, which then delivers it to a mailbox via LMTP (e.g.: the final SMTP server hands off the email to the IMAP server via LMTP usually). All of these SMTP servers behave the same: they keep retrying or bounce the message if they can't deliver within 48hs (or maybe it was 24hs?). In this case, you'd be able to replace "deliver via LMTP to an IMAP mailbox" with "deliver via LMTP to something that sends webhooks". I suppose that "pipe via curl" is basically a less-standard way of doing LMTP, but should work all the same.

crystal commented 2023年02月03日 11:12:12 +01:00

Sorry, maybe I'm not communicating adequately. I am not concerned about the message being dropped, I am concerned about the SMTP server successfully receiving the message and piping it to curl, only for that operation to fail because the Gitea server is down.

From the perspective of an average system administrator, this does seem a lot more difficult to understand than simply pointing Gitea at an IMAP account.

Sorry, maybe I'm not communicating adequately. I am not concerned about the message being dropped, I am concerned about the SMTP server successfully receiving the message and piping it to curl, only for that operation to fail because the Gitea server is down. From the perspective of an average system administrator, this does seem a lot more difficult to understand than simply pointing Gitea at an IMAP account.

fsologureng commented 2023年02月04日 22:45:44 +01:00

FWIW There is a development for this functionality at https://codeberg.org/Codeberg-Infrastructure/email-service but no progress since the Hackaton v2 where there was a team working on it.

FWIW There is a development for this functionality at https://codeberg.org/Codeberg-Infrastructure/email-service but no progress since the Hackaton v2 where there was a team working on it.

VannTen commented 2023年07月13日 11:28:18 +02:00

Since this is now released in gitea, what are the obstacles to put this in place for Codeberg ?

Since this is now released in gitea, what are the obstacles to put this in place for Codeberg ?

n0toose commented 2023年07月14日 09:59:08 +02:00

Thank you very much for reminding us about this; this feature is disabled in Gitea by default and someone has to enable it.

https://github.com/go-gitea/gitea/pull/22056/files#diff-eda333ab2034231553808ef0f99e28cd1f209c7f583fd3d0aa0fb1b77e573cd4

Thank you very much for reminding us about this; this feature is disabled in Gitea by default and someone has to enable it. https://github.com/go-gitea/gitea/pull/22056/files#diff-eda333ab2034231553808ef0f99e28cd1f209c7f583fd3d0aa0fb1b77e573cd4

tmpod commented 2024年04月08日 17:53:42 +02:00

Hey, any updates on this? It's very useful to read and reply to comments directly from my e-mail client :)

Hey, any updates on this? It's very useful to read and reply to comments directly from my e-mail client :)

fnetX commented 2024年08月29日 21:02:11 +02:00

This is currently tracked in #1562#

This is currently tracked in https://codeberg.org/Codeberg/Community/issues/1562#