Incomplete/bogus implementation of mail incoming_handler

[KazzmanK]

Description

I've setup incoming mail.
If no token in mail address provided there is a record in log
Incoming email token not found in headers

In some cases log says
Skipping automatic email reply

When token is manually truncated some letters
Error while processing incoming email[0]: unexpected EOF

But when token is intact, no log records and no new messages in issue conversation is created (I`m replying to new message in issue email)

Gitea Version

1.22.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Windows service

Database

SQLite

[KazzmanK]

I was able to get a single notification which I able to reply to. It was a first comment in new issue it was an issue creation notification.
Any other replies to other comments do not create messages in issue.

[lunny]

If you say debug and you are running Gitea in development, you can use debug mod of VSCode.

[KazzmanK]

I wasn't managed to fully get debugging environment, to make breakpoints work I needed to set "substitutePath" in launch.json. But setting this parameters breaks source browsing on breakpoint.
Nevertheless , take look at

gitea/services/mailer/incoming/incoming_handler.go

Lines 114 to 122 in e5e4078

	case *issues_model.Comment:
	comment := r
	if content.Content == "" {
	return nil
	}
	if comment.Type == issues_model.CommentTypeCode {
	_, err := pull_service.CreateCodeComment(

When I reply to new Issue (line 86), you create CreateIssueComment on line 110.
But when I reply to subsequent comments I'm routed to line 114, where only code comments somehow handled.
So, from user perspective incoming mail is just dumped.
Replying to ordinary comments in Issues is broken.

[linghengqian]

• I noticed that https://docs.gitea.com/administration/email-setup doesn't actually point out any means to directly test whether SMTP is working.
• If I had to look for an equivalent, I'd point to GitLab CE's instructions, as this is obviously very different from GitLab CE. In Chinese articles like https://www.yuque.com/linghengqian/meve2v/amyuk4s35t5ze394 , if GitLab CE is started via Docker Container, the user has a series of Bash commands similar to the following to send a test email to a real mailbox. This will start the interactive shell of the GitLab CE container and use GitLab CE's internal tool gitlab-rails console for testing. This type of operation can completely bypass the Web UI.
• The katyreid@outlook.com here is a fake email.

docker compose up -d
docker compose exec gitlab-ce /bin/bash
gitlab-rails console
Notify.test_email('katyreid@outlook.com', 'Message Subject', 'Message Body').deliver_now

• For operations similar to SMTP authentication is still failing #28335, when I sent a test email in the Web UI, the information printed by Gitea in the Web UI was relatively short. In contrast, GitLab CE emits a full error stack when executing a command like Notify.test_email('katyreid@outlook.com', 'Message Subject', 'Message Body').deliver_now.

irb(main):001:0> Notify.test_email('katyreid@outlook.com', 'Message Subject', 'Message Body').deliver_now
Delivered mail 66ca90b0e9cff_66d2fa8-46f@ed1061f8ab5f.mail (14.2ms)
/opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-protocol-0.1.3/lib/net/protocol.rb:46:in `connect_nonblock': SSL_connect returned=1 errno=0 peeraddr=172.19.0.2:587 state=error: certificate verify failed (self-signed certificate) (OpenSSL::SSL::SSLError)
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-protocol-0.1.3/lib/net/protocol.rb:46:in `ssl_socket_connect'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:690:in `tlsconnect'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:666:in `do_start'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:611:in `start'
        from /opt/gitlab/embedded/service/gitlab-rails/config/initializers/mail_starttls_patch.rb:53:in `start_smtp_session'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:2145:in `do_delivery'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:253:in `block in deliver'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:588:in `block in deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in `block in instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/activesupport-7.0.8.4/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in `instrument'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:586:in `deliver_mail'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:253:in `deliver'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/actionmailer-7.0.8.4/lib/action_mailer/message_delivery.rb:119:in `block in deliver_now'
        from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/actionmailer-7.0.8.4/lib/action_mailer/rescuable.rb:19:in `handle_exceptions'
        ... 14 levels...
irb(main):002:0> 

[KazzmanK]

@KN4CK3R , can you please take a look, is there a problem. I`ve debugged incoming mail with reply to issue comment, and it was not handled.

[KN4CK3R]

Thank you for the ping, I will have a look. We have (deactivated) integration tests which should catch if something was broken recently.

[KN4CK3R]

Fixed in #32050