Closed 130s closed 2 years ago
130s
commented
2 years ago https://github.com/ros-infrastructure/answers.ros.org/issues/206 may be relevant, although I'm not sure about that as the error msg
転送設定： ※現在、セキュリティポリシーの改訂によりGmailへのメール転送ができない場合がございます。 転送メールをご利用いただく場合は、Gmail以外のメールアドレスをご登録いただけますようお願いいたします。
Maybe this is a culprit. But this time I don't see spf in the error output.
130s
commented
2 years ago As long as I get an email that is sent to my keio address it should be ok to me.
The chain of the recipient:
xxxx@keio.ac.jp -> yyyy@gmail.comxxxx@keio.ac.jp -> (Yet another forwarding service that doesn't cause the auth error) -> yyyy@gmail.com130s
commented
2 years ago 130s
commented
2 years ago
- Opt-1:
xxxx@keio.ac.jp-> (Yet another forwarding service that doesn't cause the auth error) ->yyyy@gmail.com
I'm not sure if this resolves the issue.
yyyy@gmail.com in the example above) and the one before? What about b/w the yet-another one and xxxx@keio.ac.jp? Need to verify.130s
commented
2 years ago
- Opt-1:
xxxx@keio.ac.jp-> (Yet another forwarding service that doesn't cause the auth error) ->yyyy@gmail.comI'm not sure if this resolves the issue.
- As a end recipient, yes I now no longer see encrypt failure in the email I receive to the address that used to be causing encryption failure.
- But that can just be between my end email address (i.e.
yyyy@gmail.comin the example above) and the one before? What about b/w the yet-another one andxxxx@keio.ac.jp? Need to verify.
Updated opinion:
keio.ac.jp), for which I don't know if I can tell as a recipient (at gmail.com) whether there was any error in b/w:
TLS isn’t end-to-end encryption. This means that hackers can capture your email once it reaches the destination mail server.
130s
commented
2 years ago Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. q9-20020a17090311c900b00153b2d1657esi3869487plh.390 - gsmtp (in reply to end of DATA command)
The log in OP suggests https://support.google.com/mail/answer/81126#authentication. So authentication problem.
Which authentication is the error about? It is unclear. My guess is SPF, somewhere b/w keio and gmail. Ref.
https://www.agari.com/email-security-blog/dkim-vs-spf-do-i-need-them-both-dkim-vs-spf/
During an SPF check, receiving email servers query the DNS records associated with your sending domain to verify that the IP address used to send the email is listed in the SPF record. If it isn’t, the email will fail authentication—helping to weed out malicious emails attempting to exploit the associated domain.
B/c I don't know what problem the IT dept. at Keio U. hasn't figured out, it's hard for me if my guess is right with the info I have. I only assume keio -> gmail failed but keio -> googlegroups.com still works. So regarding email delivery, despite my earlier post https://github.com/130s/hut_10sqft/issues/665#issuecomment-1111449148, I'm now ok to say opt-1 is working fine.
This doesn't mean the minimum security that all the email services for both outgoing and inbound emails offer is available. I'm not educated to say that yet.
130s
commented
2 years ago Hmm...https://stackoverflow.com/questions/71157383/this-message-does-not-have-authentication-information-or-fails-to-550-5-7-26-pas someone having an issue with GMail even though the checkers for all SPF, DKIM, DMARC passed.
Anwyays, I'm leaning toward assuming TLS is not failing at least b/w the sender and jukuin.keio.ac.jp. Asked security.stackexchange.com#q261730 for clarifying that.
130s
commented
2 years ago Once again I reviewed an example email that GMail warns as "keio.ac.jp (recipient) did not encrypt this message". From what I can tell from email headers, jukuin.keio.ac.jp doesn't seem to log encryption.
When GMail.com receives an email from the server of an interest, I do not see any log about encryption.
Received: from kolmail1.jukuin.recipient.org (kolmail1.jukuin.recipient.org. [xxx.xxx.134.67])
by mx.google.com with ESMTP id b13-20020a63cf4d000000b00398d40dfc06si21118457pgj.482.2022.04.26.12.51.47
for <RECIPENT-GMAIL-ACCT@gmail.com>;
Tue, 26 Apr 2022 12:51:48 -0700 (PDT)Btw, "How Can You Tell if an Email Was Transmitted Using TLS Encryption?" (luxsci.com) helps me a lot to understand how to interpret the header of an email to see if its pathway is encrypted or not.
130s
commented
2 years ago Closing for now.
As a final confirmation, I sent an email to the organizer of this email forwarding service. Will post an update once I receive their response, but I'm "satisfied" with the result of my research for now.
Don't know how often this is happening, but if it happens, I would not be aware that I'm not receiving the email. So this is critical.
Example log
``` From: MAILER-DAEMON@kolmail1.jukuin.keio.ac.jp (Mail Delivery System) Subject: Undelivered Mail Returned to Sender Date: April 20, 2022 20:34:16 EDT To: xxxx@yyyyyy.yyyyyy This is the mail system at host kolmail1.jukuin.keio.ac.jp. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system