fix: Use maintainerEmail instead of email for incoming mail

[MomentQYC]

What

see the title

Why

Many SMTP services do not usually receive mail, and sending it can lead to soft bounces and unnecessary waste of resources

Additional info (optional)

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Add story of storybook
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[github-actions]

このPRによるapi.jsonの差分
差分はありません。
Get diff files from Workflow Page

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 19.34%. Comparing base (a11b77a) to head (8cabd48).

Additional details and impacted files

@@             Coverage Diff              @@
##           develop   #14893       +/-   ##
============================================
- Coverage    39.47%   19.34%   -20.13%     
============================================
  Files         1560      727      -833     
  Lines       197081   103537    -93544     
  Branches      3614      990     -2624     
============================================
- Hits         77803    20033    -57770     
+ Misses      118706    82951    -35755     
+ Partials       572      553       -19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[samunohito]

Thank you for the pull request. Are there any issues that mention this issue in detail?

[MomentQYC]

Thank you for the pull request. Are there any issues that mention this issue in detail?

I didn't search for the issue in issues (maybe I didn't search in the right way), but it's a real problem. When the system's SMTP service does not support incoming mail, the issue recurs 100% of the time, as evidenced by outgoing mail being discarded or bounced, but you still have to pay for this outgoing mail.

[beixibaobao]

Thank you for the pull request. Are there any issues that mention this issue in detail?

I'll provide a detailed report along with the reproduction process

As long as you set up mail SMTP, it may cause a wrong mail request regardless of who and how you set up the reported notification.
[It will happen when the mail service provider bans itself from sending mail to itself.]
Recurrence:
When you use Zeptomail as your mail service provider, assuming that your SMTP outbox is set to “[email protected]”, and you encounter a reported complaint, the program will send a report notification using “notice@yourdomain. com” to send a report notice to ‘[email protected]’.
In zeptomail's opinion, such a way of sending an email to yourself is wrong and the platform carries out a soft bounce, but zeptomail believes that the platform should not be held responsible for the loss, so the user should pay for this sending.
So this faulty logic caused loss of assets.

[sousuke0422]

私のインスタンスでは簡易的なスパム対策のため、user at example.comをの形式でメアドを入れてるはずなので運用によっては問題が発生します。

---

In my instance, for simple anti-spam measures, the mail address should be in the form of user at example.com, so it may cause problems depending on the operation.

[MomentQYC]

私のインスタンスでは簡易的なスパム対策のため、user at example.comをの形式でメアドを入れてるはずなので運用によっては問題が発生します。

---

In my instance, for simple anti-spam measures, the mail address should be in the form of user at example.com, so it may cause problems depending on the operation.

There seems to be two solutions now, either just remove this part of the code or determine if this is a valid mailbox

[eternal-flame-AD]

I think using maintainer email is the right logic just need more sanity checks, like if the sending email is the same as the maintainer email (which should be discouraged in the first place at setup ideally, it is a significant security risk configuring a credential that both send and receive email) and maybe only use this as the last fallback when nothing else is set up.

[eternal-flame-AD]

Somewhat related: system emails should have a Reply-To header to prevent accidentally replying to SMTP only services.

Reference impl: https://forge.yumechi.jp/yume/yumechi-no-kuni/commit/283738d5e76360901b389ece48bbd7c1ccc460e6

[fruitriin]

あーーー、実際に送信に使われるメールアドレスではなくて、システムが送信するメールの返信先としてコンパネ>一般>管理人のメールアドレスが採用されているということですか？
私はこのIssueがOpenされてからずっと動向を伺っていましたが、ようやくひとつの納得を得ることができました。

だとするならば、それはコンパネのメールの設定に項目を追加するなどを行うべきで、少なくともメンテナ(これはMisskeyを公式ではなくForkして改変した場合のコードのメンテナ)のメールアドレスを使うべきではないと思います

[MomentQYC]

Given that the discussion has been too chaotic, I have directly strengthened the email validation. If this works, then this will be the final version

[eternal-flame-AD]

I received by private mail comments regarding some confusion caused by this so I will post a more comprehensive context on this comment and why I think it is relevant to this issue:

Somewhat related: system emails should have a Reply-To header to prevent accidentally replying to SMTP only services.

Reference impl: https://forge.yumechi.jp/yume/yumechi-no-kuni/commit/283738d5e76360901b389ece48bbd7c1ccc460e6

The original issue is the sending email and the maintainer email can loop back, which I have responded directly in a previous comment. I considered my Reply-To header patch and think it is related (although does not directly solve this issue does deal with the same set of problems of sending emails to places not designed to receive email thus I started with saying "somewhat related").

The "sanity check" I was referring is mainly regarding sub addressing (rfc5233) not the validity of the email itself (that would be an apparent configuration issue and any sanity checks should be done at configuration not here). admin+no-reply@ and admin@ is the same email user. They technically could be delivered differently but it is a security concern to share credentials this way so I think for the purpose of sending abuse notifications we should not attempt to deliver a notification to a different sub address.