幹壞事是進步最大的原動力
在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題，引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。
SMTP 裡 STARTTLS 的設計雖然可以加密，但仲所皆知，可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線，而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為：
可以看到突尼西亞的監控情況遠超過想像...
目前的想法是發展一套類似 HSTS 的 Trust on first use 設計，也許在這份報告出來後可以加速催生...
在 OSNews.com 上看到 Google 的 Customer Match 讓你可以針對某個特定帳號 (用 e-mail 辨別) 下廣告：「Google lets companies target ads using your email adress」。Google 的文章在「Google brings you closer to your customers in the moments that matter」這邊。
Customer Match 允許你直接針對某個人下廣告：
Customer Match allows you to upload a list of email addresses, which can be matched to signed-in users on Google in a secure and privacy-safe way.
侵犯隱私並且提供 APT 攻擊 (Advanced persistent threat) 一個避開偵測的管道。
這也是為什麼應該裝「uBlock Origin」(Google Chrome) 的原因之一：在網路上你要學會用各種工具保護自己。
之前 Amazon SES 只能拿來發信，現在可以收信了：「New – Receive and Process Incoming Email with Amazon SES」。
收信下來後可以放到 S3，也可以用 SNS 接，或是用 Lambda 處理。除此之外還有 Spam & Virus 檢查的功能...
一時間想不到用途 :o
Slack 的新功能，可以寄信到 Slack 的 Channel 裡：「Email, meet Slack. Slack, email.」。
這個新功能限制在付費使用者才能使用：
Today we’re launching a new feature: all teams on the Standard or Plus plans can have email directed into Slack channels.
包括圖片也是可以顯示出來的：
這樣接起來更方便了...
在 Hacker News Daily 上看到的服務：「CuttlePhish」。
CuttlePhish 是個社交工程演練網站，提供演練測試 (Phishing as a Service)，付費的方式也很有趣：
Twenty bucks, for up to 100 users. We charge per-batch of emails, (not per-email or per-click). You only pay if somebody clicks one of the links in our emails.
只有在有人點的時候收 USD$20... XD
Facebook 宣佈支援 PGP 機制：「Securing Email Communications from Facebook」。
有兩個功能，首先是可以讓別人查詢。
另外一個是可以要求 Facebook 寄給你的信件都用這把 Key 加密。
如果有 API 可以拉出資料的話就更好了...
Amazon WorkMail 在今年一月底時推出 Preview (參考「Amazon 跨足 Email 市場」)，需要填單申請。
昨天發現申請到了，由於 Amazon WorkMail 只有 us-west-1 與 eu-west-1 有服務，所以在 us-east-1 開了一個 domain 測試。
帳號與 IAM 分開，另外吃 AWS Directory Service，我是透過 Simple AD 管理帳號。
由於目前不支援 POP3 與 IMAP，所以也不用在這折騰了：(Amazon WorkMail FAQs)
Q: Can I use Amazon WorkMail with my existing POP3 or IMAP clients?
No, Amazon WorkMail currently does not offer support for POP3 or IMAP clients.
所以這次先只看 webmail 的部份。
以一個用 Gmail 用習慣的人 (而且用快速鍵已經很順手了)，邊翻文件邊用，過十分鐘後就覺得「好陽春啊」...
快速鍵能做的事情相當少，大多都還是要用鍵盤操作。另外看得出來沒有 preload，翻下一封信的時候還是要等待一下。
另外沒有 Send as 的功能 (舉例來說，我雖然是 ooxx@gmail.com，但我可以透過認證後以 ooxx@kkbox.com 的 From 寄出信件)，對外很不方便。
還有一些是 bug，修掉應該只是時間的問題。像是我把 preview 位置改成 bottom 後，再把 preview 視窗拉大，切到 setting 再切回來又變回原來的視窗大小了。
離「可以用」的等級還有點遠 (現在是屬於「不能用」的等級)，先這樣放著吧...
大清早就看到「Amazon WorkMail – Managed Email and Calendaring in the AWS Cloud」這個消息。
Amazon WorkMail 的價位是 USD$4/user (50GB 空間)，包括了 mail 與 calendar 的功能：
或是加上 Amazon WorkDocs，需要 USD$6/user。
翻了一下 Google Apps for Work，是 USD$6/user (30GB 空間) 以及 USD$10/user (進階功能，加上無限空間)。
不過目前只支援 us-east-1 與 eu-west-1 兩個區域，而且是 Preview 狀態 (表示需要填單申請)。也許先測看看，好用的話就來等 ap-northeast-1？
在「“Invalid Username or Password”: a useless security measure」這篇文章裡談到了使用者登入錯誤時的提示訊息。
通常為了安全考量，「沒有這個帳號」與「密碼錯誤」，我們會給出一樣的錯誤訊息，避免攻擊者可以猜測。像是 Amazon 的畫面：
這樣設計的前提是讓攻擊者不知道這個帳號是不是存在 (如果不存在的話就換其他帳號繼續攻擊)。但這個假設通常是錯的，因為大多數的系統一個 e-mail 綁定一個帳號，所以註冊時就可以分辨：
因此應該提供正確的訊息，而非將資訊隱蔽起來。
在「Facebook Yahoo Require-Recipient-Valid-Since SMTP Extension」這篇看到 Require-Recipient-Valid-Since (RRVS) 變成 Proposed Standard 了：「The Require-Recipient-Valid-Since Header Field and SMTP Service Extension」(RFC 7293)。
起因是從 2013 年的「yourname@yahoo.com Can Be Yours!」這篇開始的：Yahoo! 宣佈會釋出太久沒有使用的 @yahoo.com 帳號讓其他人可以註冊。
而這導致了帳號綁定問題：如果使用者先前在 Facebook 上 (或是其他服務) 有綁定 Yahoo! 帳號，而他的 Yahoo! 帳號被釋出被其他人拿走後，其他人就可以利用重設密碼的功能取得 Facebook 帳號權限。
Yahoo! 對這個問題的解法是透過 Require-Recipient-Valid-Since 處理，服務方 (像是 Facebook) 在發出重要信件時帶入 Require-Recipient-Valid-Since，要求這封信必須在某個時間點後有效，才能讓收信者看到這封信的內容。
Facebook 的人在「Protecting Facebook Accounts With New Email Standard」也提到了這個新標準。