新潮email應用程式瘋Gmail支援，生態變革中…
有時候在網路上晃，看見一張照片，好像是出自某個叫 Stephen Phillips 的攝影師吧？地點或許是在哪間咖啡廳，燈光很柔和。最近，有不少人開始討論一種叫 Tejido 1.0.0 的新東西，不過細節其實不是那麼清楚。倒是關於電子郵件軟體這事，大家的注意力好像都被那些只支援 Gmail 的應用程式給吸引了。到底為什麼會這樣？是不是 IMAP 這個協議快沒人用了？
偶爾在 Mac O’Clock 上瀏覽 Medium，文章多到數不清，大致七十來篇裡頭就能看到幾篇提到這類話題。有些作者分享他們自己的觀察，也有人只是順帶一提。作為寫手，大概也只是想看看其他人在寫些什麼內容，畢竟靈感有時候就藏在別人的句子裡。
說起來，IMAP 好像還沒真的消失，只是存在感變得比較淡，有些產品根本沒考慮要支援它。有的人甚至覺得現在要找一款能同時兼容多種郵箱服務的客戶端已經沒有從前那麼容易了。不過話說回來，也許只是剛好最近熱門軟體都特別偏愛 Gmail 吧。未來會不會又流行回去，其實誰也講不準。
偶爾在 Mac O’Clock 上瀏覽 Medium，文章多到數不清，大致七十來篇裡頭就能看到幾篇提到這類話題。有些作者分享他們自己的觀察，也有人只是順帶一提。作為寫手，大概也只是想看看其他人在寫些什麼內容，畢竟靈感有時候就藏在別人的句子裡。
說起來，IMAP 好像還沒真的消失，只是存在感變得比較淡，有些產品根本沒考慮要支援它。有的人甚至覺得現在要找一款能同時兼容多種郵箱服務的客戶端已經沒有從前那麼容易了。不過話說回來，也許只是剛好最近熱門軟體都特別偏愛 Gmail 吧。未來會不會又流行回去，其實誰也講不準。
Mimestream與Gmail專屬API，功能導向的選擇！
最近好像有不少人在討論某個郵件應用，名字記得叫做 Mimestream。有趣的是，這工具目前只支援 Gmail，其他信箱就沒辦法用了。其實這樣的設計也不算特別奇怪啦，畢竟他們也說自己會針對 Gmail 裡頭那些功能去做一些優化和調整。
然後前陣子 Notion 也發表了一個新東西，好像叫 Notion Mail。Notion 應該很多人都聽過吧，就是那個筆記軟體。不過我自己還是比較習慣用純文字來記東西，有幾個原因啦，也不是什麼大問題。
Notion 推出自己的郵件服務那一天，不少圈內人看起來挺在意的。有些朋友甚至覺得這可能會帶來一點變化，但實際狀況怎麼樣好像還得觀察。反正現在各種郵件工具愈來愈多，每隔一段時間就冒出新選擇，不知道大家最後會怎麼選就是了。
然後前陣子 Notion 也發表了一個新東西，好像叫 Notion Mail。Notion 應該很多人都聽過吧，就是那個筆記軟體。不過我自己還是比較習慣用純文字來記東西，有幾個原因啦，也不是什麼大問題。
Notion 推出自己的郵件服務那一天，不少圈內人看起來挺在意的。有些朋友甚至覺得這可能會帶來一點變化，但實際狀況怎麼樣好像還得觀察。反正現在各種郵件工具愈來愈多，每隔一段時間就冒出新選擇，不知道大家最後會怎麼選就是了。
Comparison Table:
| 主題 | IMAP的特點與挑戰 |
|---|---|
| 易用性 | IMAP結構複雜，對開發者不夠友善，需要處理多層次的內容描述。 |
| 下載方式 | 可以選擇直接下載整封信及附件，而非手動解析內容。 |
| 市場佔有率 | Gmail約占30%市場，其它服務如Apple Mail也有相當比例，顯示市場競爭性。 |
| 未來展望 | IMAP可能持續存在至2030年，但面臨API取代的挑戰，如Gmail API等新技術。 |
| 郵件整合工具 | Tejido等工具能有效整合多平台郵件，提升使用便利性 |
Notion Mail亮相、筆記軟體跨足郵件領域#
說到筆記軟體這個圈子，Notion差不多是大家都會提起的名字，有時候甚至感覺到處都在用。嗯，它最近居然也跑來做電子郵件應用，這還挺讓人想湊熱鬧看看。我自己大概也是跟著好奇心去瞄了一眼，就真的有那麼回事。
不過仔細看下去，好像現階段它只能連接Google的郵箱帳號——其他那些信箱服務商，什麼Yahoo啦、Outlook啊、或是國內某些廠牌，暫時都沒看到支援。感覺上，Notion似乎把重心先放在一個比較主流的大品牌，但其實外頭選擇還真不少。有些朋友就疑惑為什麼只顧著Google？可能之後會慢慢加進來吧，不過現在好像只有一種選項。
有的人說Notion靠著這波新產品收入應該不錯，可是這個「僅限Google」的小設定，倒也讓部分期待多元整合的人稍微失落。未來怎麼樣很難講，目前看到的大致就是這樣。
不過仔細看下去，好像現階段它只能連接Google的郵箱帳號——其他那些信箱服務商，什麼Yahoo啦、Outlook啊、或是國內某些廠牌，暫時都沒看到支援。感覺上，Notion似乎把重心先放在一個比較主流的大品牌，但其實外頭選擇還真不少。有些朋友就疑惑為什麼只顧著Google？可能之後會慢慢加進來吧，不過現在好像只有一種選項。
有的人說Notion靠著這波新產品收入應該不錯，可是這個「僅限Google」的小設定，倒也讓部分期待多元整合的人稍微失落。未來怎麼樣很難講，目前看到的大致就是這樣。
Google帳號唯一？Notion只愛Gmail現象分析*
嗯……這個嘛，其實我大致上想得到原因。最近剛好在搞自己的信箱程式，所以腦中還留著一些相關的細節。Gmail有給開發者一種API，這東西聽說用起來算方便，特別是他們那種偏現代的網路標準，好像叫REST吧，有些人也會提到什麼API憑證、JSON格式……總之跟老方法不太一樣。
但如果沒打算用Gmail提供的API，也不是不能做啦，只是得靠IMAP協議——這東西其實滿久以前就有了。以前我寫過一篇愚人節文章，大概提到過IMAP的一些狀況，記憶裡應該就是那時候開始弄Tejido（反正是個收信的小工具）。它要抓信件時就是用IMAP跑資料。
說真的，IMAP感覺有點像舊時代留下來的產物，不管怎麼說都跟現在流行的那些Web API差了一大截。當然不是完全不能用，只是你要處理各種奇怪的小細節。想著想著，不知不覺就繞回來原本那個問題了：為什麼很多應用都更傾向直接整合Gmail API？或許部分原因就在於開發流程順手很多，雖然偶爾還是有人堅持傳統方式——只是不一定適合所有情境啦。有的人可能覺得新系統比較單純，有些人則懷念舊工具帶來的彈性。不過現在回頭看，其實哪條路都不是萬無一失，就看需求和習慣了。
但如果沒打算用Gmail提供的API，也不是不能做啦，只是得靠IMAP協議——這東西其實滿久以前就有了。以前我寫過一篇愚人節文章，大概提到過IMAP的一些狀況，記憶裡應該就是那時候開始弄Tejido（反正是個收信的小工具）。它要抓信件時就是用IMAP跑資料。
說真的，IMAP感覺有點像舊時代留下來的產物，不管怎麼說都跟現在流行的那些Web API差了一大截。當然不是完全不能用，只是你要處理各種奇怪的小細節。想著想著，不知不覺就繞回來原本那個問題了：為什麼很多應用都更傾向直接整合Gmail API？或許部分原因就在於開發流程順手很多，雖然偶爾還是有人堅持傳統方式——只是不一定適合所有情境啦。有的人可能覺得新系統比較單純，有些人則懷念舊工具帶來的彈性。不過現在回頭看，其實哪條路都不是萬無一失，就看需求和習慣了。
開發者角度：Gmail API vs IMAP協定難題。
IMAP4rev1這個東西啊，說起來距今應該有二十多年了吧，怎麼算也差不多超過一個世代。它的設計，有點像老派的感覺，不太搭現代人的習慣。你找不到什麼REST API，只有那種很直接的TCP連線方式；如果想看到JSON格式，大概要失望了，眼前只剩下一些比較像是自家獨門的資料結構。至於時間日期嘛，也不是大家現在熟悉的ISO 8601——其實好像更正式點該叫RFC 3339？不過這話題本身就容易吵起來。有趣的是，他們偏偏還用了幾種不同的日期寫法，看得人偶爾會糊塗。反正細節很多，有時候研究半天還是摸不清楚到底哪個才是主流做法。
IMAP4rev1規格老舊又複雜，還有格式地獄#
IMAP這玩意兒，好像一直都讓人感覺不太友善。說起來，裡頭藏著那種很奇怪的東西──像是什麼bodystructure，搞得有點複雜。其實，如果只是單純想把整封信，包括那些附件，一股腦全抓下來，貌似根本不用去理會那些結構描述。不過，不曉得為什麼，就是有人會堅持要自己處理內容而不是直接下載所有東西。有些時候，甚至開始懷疑這樣做到底值不值得，畢竟直接把全部資料拉下來也沒多麻煩。
還記得IMAP在設計時，好像考慮到用戶會在終端機看信，所以才搞出一堆限制，比如行長不能超過某個範圍，還有那種有點詭異的Q編碼。總之，格式很難說有多直觀，有種不上不下的混合感。
解析IMAP嘛……嗯，其實花費的精力不少。有些程序員碰到這類括號、層層巢狀結構時會覺得挺頭大的，也遇過有人抱怨「怎麼可能叫人家手動找括號配對」之類的問題。這情況好像在某次面試還真發生過。如果碰巧對這部分比較敏感，大概就需要多一點耐心吧。
還記得IMAP在設計時，好像考慮到用戶會在終端機看信，所以才搞出一堆限制，比如行長不能超過某個範圍，還有那種有點詭異的Q編碼。總之，格式很難說有多直觀，有種不上不下的混合感。
解析IMAP嘛……嗯，其實花費的精力不少。有些程序員碰到這類括號、層層巢狀結構時會覺得挺頭大的，也遇過有人抱怨「怎麼可能叫人家手動找括號配對」之類的問題。這情況好像在某次面試還真發生過。如果碰巧對這部分比較敏感，大概就需要多一點耐心吧。
解析IMAP bodystructure痛苦歷程＠技術碎碎念。
有些寫程式的，感覺像是那種平常會吃點西式蛋餅的人，可能嫌IMAP麻煩，就直接跑去用Gmail API搞開發了，結果一不小心，他們做的東西只吃得下Google那邊的帳號。這件事我原本也動過念頭，大概有想了好幾天吧。不過後來看到一個畫面（不是很確定哪來的截圖），上面意思大致就是Google自己也沒特別推薦大家拿Gmail API來做郵件應用，那時我就稍微猶豫了一下——畢竟官方都說不建議，我想大部分人遇到這種情況多半會選擇繞道而行吧。我最後也是順著他們的話沒去碰。現在回頭想，好像也未必是錯，但要說後悔，也談不上啦。或許如果沒有人工智慧工具這種東西，我會覺得卡住，不過最近那個Gemini還算蠻給力的，每次問它IMAP怎麼搞，都能解答一些疑惑。有時候資訊多了反而會讓人搖擺，有些細節記不得太清楚，只能模模糊糊講出個大概，但目前看起來，選擇繼續用IMAP，好像還行。
開發者偏好API，棄IMAP只為減少麻煩…@
一開始弄 IMAP 的時候，其實還是花了一點時間才搞定。現在不用被 Gmail 綁死，反而覺得比較自由。像我自己有個 andrewzuo.com 的網域信箱，是用 Zoho mail，那個以前都是直接設成自動轉發到 Gmail，圖個方便。結果後來有了 Tejido 這工具，可以把所有郵件都整合在一起看，就不必再靠那種轉寄的方式了，感覺上還滿省事。
這樣下來，其實支援的信箱服務變多，好像也算是一種小小優勢吧？畢竟 Gmail 雖然大家都說很大，但如果查一下資料，他們大概也就占差不多三成左右的市場——沒有想像中那麼壟斷啦。蘋果的信箱系統其實排在第二，只是之前沒特別注意。說真的，我也曾經考慮是不是要把 andrewzuo.com 那邊直接切去 Apple Mail，用起來可能會不太一樣。不過話又說回來，每家服務各有自己的習慣和小毛病，有些選擇最後還是得試過才知道合不合適。
總之啊，現在能同時看好幾個平台的郵件，偶爾還會想，到底是不是該換個主力收信管道。但目前好像就先這樣吧，哪天需要再說好了。
這樣下來，其實支援的信箱服務變多，好像也算是一種小小優勢吧？畢竟 Gmail 雖然大家都說很大，但如果查一下資料，他們大概也就占差不多三成左右的市場——沒有想像中那麼壟斷啦。蘋果的信箱系統其實排在第二，只是之前沒特別注意。說真的，我也曾經考慮是不是要把 andrewzuo.com 那邊直接切去 Apple Mail，用起來可能會不太一樣。不過話又說回來，每家服務各有自己的習慣和小毛病，有些選擇最後還是得試過才知道合不合適。
總之啊，現在能同時看好幾個平台的郵件，偶爾還會想，到底是不是該換個主力收信管道。但目前好像就先這樣吧，哪天需要再說好了。
放棄Gmail API警語，轉戰多元郵件服務支援。
其實現在很多人訂閱 iCloud 之後，內建的郵件功能大概就夠用了。Notion Mail 或 Mimestream 這類信箱應用偶爾會被提起，不過說真的，大部分人最後還是用不上，因為它們得靠 Gmail 那套 API 才能跑。Tejido 好像沒這個問題。但 IMAP 這種規範老舊又有點難搞，結果變成一種微妙的門檻，把某些比較偏好簡單開發方式的人擋在外頭。
話說回來，有時候想想，也許哪天郵件服務供應商乾脆不玩 IMAP 了，換成像 Gmail 那樣的 API？這感覺有點像以前 Google Reader 的 API——雖然那服務都停掉很久了，但還是被一些 RSS 閱讀器沿用著。不過，要全部轉換成那種新系統，大概也不是短時間可以完成的事吧。畢竟電子郵件服務本身，好多年都沒什麼新面孔冒出來，更新速度慢得讓人差點忘記它其實也算科技產品之一。有時候要等到新的郵件平台問世，那真的是可遇不可求。
話說回來，有時候想想，也許哪天郵件服務供應商乾脆不玩 IMAP 了，換成像 Gmail 那樣的 API？這感覺有點像以前 Google Reader 的 API——雖然那服務都停掉很久了，但還是被一些 RSS 閱讀器沿用著。不過，要全部轉換成那種新系統，大概也不是短時間可以完成的事吧。畢竟電子郵件服務本身，好多年都沒什麼新面孔冒出來，更新速度慢得讓人差點忘記它其實也算科技產品之一。有時候要等到新的郵件平台問世，那真的是可遇不可求。
未來郵件標準迷思：IMAP消亡或API全面接管！
最近還在運作的，好像就剩下Hey這個服務了吧，聽說它也有提供IMAP。感覺IMAP這東西應該還會陪著大家過好幾年，可能得撐到二〇三〇左右？不太確定啦，到那時候說不定有人終於會想動手改一改IMAP的規範。不過講真的，也許沒那麼容易，因為IMAP看起來比較像給人拿來在終端機裡頭看信件的工具，各種新功能和安全驗證、甚至Q編碼、Base64什麼的，都陸續被加進去，一層又一層。結果反而變得更複雜。要說未來郵件會靠IMAP發展嘛，好像也不是這麼回事。有些人現在已經開始往API去，例如Gmail那類介面，看起來比較靈活，但是不是所有人都能接受或是適用，其實還很難說。
