アカウント名:
パスワード:
カレンダーのOAuth認証はまあ分かるけど、GmailのOAuth認証強制は面倒が増えるだけ。IMAP/POP/SMTPといった標準的なプロトコルによる認証がすでにあるんだから、それに従って欲しい。セキュリティ強化ならGoogleアカウントとは別にGmail専用の第2パスワード(アプリパスワード)を払い出せば済む話だったのをOAuthで統一しようとするからおかしなことになる。
全くもってしらないのだがSMTPにあるプロトコルに定義された標準的な認証って具体的に何?寧ろ無かったから後からSMTP-AUTHをひっつけたと思うんだけどマジで知らないので具体的に教えて欲しい
IMAPの場合はSASLで任意の認証して構わないのでOAuth2.0による認証を標準化するのは十二分にプロトコルにある標準的な認証だと思うんだけどこのレイヤーに従ってるのに一体全体何が標準的じゃないの?
だからそのSMTP-AUTHじゃないの?
SMTP標準にはSMTP-AUTHは含まれてませんSMTP全体の仕様には含まれてるけど
「SMTP標準にはSMTP-AUTHは含まれてません」という解釈を採用すると、#4213314の言う「IMAP/POP/SMTPといった標準的なプロトコルによる認証」(のうち少なくともSTMPの場合)は何を意味するのか?という疑問が生じる。
SMTP標準はRFC5321SMTP-AUTHはRFC2554最新のSMTP-AUTHはRFC4954でSASLになってるから任意の認証でステータスコード返せば良いはずっすよ
だから、RFC標準として番号が違うからSMTP標準にSMTP-AUTH(古いID/PASS認証)は含まれてない
そしてOAuth 2.0もSASLで認証手順として使用でき、RFC 6750とRFC 7628で標準化されている。元コメの「標準的なプロトコルによる認証がすでにあるんだから、それに従って欲しい」という要求は完全に叶えられているとしか思えないのだが何が気に食わないのだろうか。
# 素直に「二段階認証ウゼェ」と言えばいいのに
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
余計なことすんなと (スコア:0)
カレンダーのOAuth認証はまあ分かるけど、GmailのOAuth認証強制は面倒が増えるだけ。
IMAP/POP/SMTPといった標準的なプロトコルによる認証がすでにあるんだから、それに従って欲しい。
セキュリティ強化ならGoogleアカウントとは別にGmail専用の第2パスワード(アプリパスワード)を払い出せば済む話だったのをOAuthで統一しようとするからおかしなことになる。
Re: (スコア:0)
全くもってしらないのだがSMTPにあるプロトコルに定義された標準的な認証って具体的に何?
寧ろ無かったから後からSMTP-AUTHをひっつけたと思うんだけど
マジで知らないので具体的に教えて欲しい
IMAPの場合はSASLで任意の認証して構わないのでOAuth2.0による認証を標準化するのは
十二分にプロトコルにある標準的な認証だと思うんだけど
このレイヤーに従ってるのに一体全体何が標準的じゃないの?
Re: (スコア:0)
だからそのSMTP-AUTHじゃないの?
Re: (スコア:0)
SMTP標準にはSMTP-AUTHは含まれてません
SMTP全体の仕様には含まれてるけど
Re: (スコア:0)
「SMTP標準にはSMTP-AUTHは含まれてません」という解釈を採用すると、#4213314の言う「IMAP/POP/SMTPといった標準的なプロトコルによる認証」(のうち少なくともSTMPの場合)は何を意味するのか?という疑問が生じる。
Re: (スコア:0)
SMTP標準はRFC5321
SMTP-AUTHはRFC2554
最新のSMTP-AUTHはRFC4954でSASLになってるから任意の認証でステータスコード返せば良いはずっすよ
だから、RFC標準として番号が違うからSMTP標準にSMTP-AUTH(古いID/PASS認証)は含まれてない
Re:余計なことすんなと (スコア:0)
そしてOAuth 2.0もSASLで認証手順として使用でき、RFC 6750とRFC 7628で標準化されている。元コメの「標準的なプロトコルによる認証がすでにあるんだから、それに従って欲しい」という要求は完全に叶えられているとしか思えないのだが何が気に食わないのだろうか。
# 素直に「二段階認証ウゼェ」と言えばいいのに