Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot send mail after merge when Username contains UTF8 character #2102

Closed
2 of 7 tasks
Avalancs opened this issue Jul 3, 2017 · 10 comments · Fixed by #2559
Closed
2 of 7 tasks

Cannot send mail after merge when Username contains UTF8 character #2102

Avalancs opened this issue Jul 3, 2017 · 10 comments · Fixed by #2559
Labels
Milestone

Comments

@Avalancs
Copy link

Avalancs commented Jul 3, 2017

  • Gitea version (or commit ref): 1.1.2
  • Git version: git version 2.13.0.windows.1
  • Operating system: Windows Server 2016 Standard
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant (cannot view logs)
  • Log gist:
    2017/07/03 12:14:19 [...les/mailer/mailer.go:244 processMailQueue()] [E] Failed to send emails [username@mycompany.com]: Subject: [Project] description (Small UI fixes on full width form titles #16), issue comment - gomail: could not send email 1: gomail: invalid address "=?UTF-8?q?"P=C3=A9ter"_git@mycompany.com?=": mail: expected single address, got "?="

Description

After merging a commit in one of our repositories, I saw this in the log, which says it was unable to deliver the notification.

P=C3=A9ter

Should be

Péter

which is used as the Full name for that user (acquired through Active Directory), so I think the latin/utf8 character

é

causes the mentioned error.

@lunny lunny added the type/bug label Jul 3, 2017
@lunny lunny added this to the 1.x.x milestone Jul 3, 2017
@lafriks
Copy link
Member

lafriks commented Jul 3, 2017

Seems to be validation problem as UTF-8 email address is correct

@Avalancs
Copy link
Author

Avalancs commented Jul 3, 2017

I'll check tomorrow if this happens all the time, since I do remember receiving some notifications. Is the error message for not being able to deliver mails because e.g. the mail server is not available the same, or different?

@lafriks
Copy link
Member

lafriks commented Jul 3, 2017

I could be wrong but seems to be validation in Gitea code

@rems4e
Copy link
Contributor

rems4e commented Sep 8, 2017

I'm facing this problem right now, where all of the people in my team have a name with characters out of basic latin character set… So none of them are receiving the emails :)

By the way the emails are generated by tickets update, if that's relevant.

Gitea is in version 1.1.4.

@Avalancs
Copy link
Author

Avalancs commented Sep 8, 2017

Hi rems4e,

Our workaround for the problem was to replace/remove these characters in the Gitea database (since the full name was coming from AD we could not edit it on the UI) and since then everyone is receiving emails.

@rems4e
Copy link
Contributor

rems4e commented Sep 8, 2017

Hi,

Thanks for the hint. But this is not really acceptable for us, as the directory is used for other stuffs that can't accomodate with this change.

Anyway, this is a bug in Gitea that is a little cumbersome at the moment :) Maybe I could have a look and try fixing it?

@lafriks
Copy link
Member

lafriks commented Sep 8, 2017

@rems4e you are more than welcome to try to fix it and send PR

@rems4e
Copy link
Contributor

rems4e commented Sep 8, 2017

@lafriks OK, that should be feasible. However, could you please hint me where to start? Mainly, on which branch should I base my work? I've had a look at the contributing info but I'm not sure it answers all of my questions :)

lunny pushed a commit that referenced this issue Sep 21, 2017
* Fix sending mail with a non-latin display name. #2102

Signed-off-by: Rémi Saurel <contact@remi-saurel.com>

* Take into account the possibility that setting.MailService.From is in `name <email@address>` format. #2102

Signed-off-by: Rémi Saurel <contact@remi-saurel.com>
@lafriks lafriks modified the milestones: 1.x.x, 1.3.0 Sep 21, 2017
@rems4e
Copy link
Contributor

rems4e commented Oct 12, 2017

I was hoping this could be in the 1.2.0 release. Is there something I can do to see it in 1.2.X ?

@lafriks
Copy link
Member

lafriks commented Oct 12, 2017

@rems4e Backporting all fixed issues to 1.2 will take too much time. I think we will release 1.3-rc in coming weeks :) we are trying to switch to faster release cycle to not have such problems that we had with 1.2

lafriks pushed a commit that referenced this issue Oct 26, 2017
* Fix sending mail with a non-latin display name. #2102

Signed-off-by: Rémi Saurel <contact@remi-saurel.com>

* Take into account the possibility that setting.MailService.From is in `name <email@address>` format. #2102

Signed-off-by: Rémi Saurel <contact@remi-saurel.com>
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
6543 pushed a commit to 6543-forks/gitea that referenced this issue Feb 26, 2024
Files can have an RSS feed, but those only make sense when taken in the
context of a branch. There is no history to make a feed of on a tag or a
commit: they're static. Forgejo does not provide a feed for them for
this reason.

However, the file view on the web UI was offering a link to these
non-existent feeds. With this patch, it does that no longer, and only
provides a link when viewing the file in the context of a branch.

Fixes go-gitea#2102.

Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b48d21ea7459539dfb1ca5cadd6f9cb99e65fc7)
(cherry picked from commit 70cb2667603bcdb9a8c9bb20c482877ab3f6de39)
(cherry picked from commit 69b45c3feaf92454853ef9b02c9d75092780dabf)

Conflicts:
	options/locale/locale_en-US.ini
	https://codeberg.org/forgejo/forgejo/pulls/2249
(cherry picked from commit 639a2c07411e6c606dfb81f695fddbad73dca3da)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants