Dell Latitude 7390 開箱

早在之前的 New XPS 13 在手時，就一直覺得這麼好的窄邊框設計怎麼不放在 Latitude 系列上，變成 New XPS 13 的優點變成窄邊框螢幕，而 Latitude 則是有完整的外接埠(HDMI, 網路)，兩個井水不犯河水，看你喜歡哪一個。

一直到去年的 7380 出現，才讓我眼睛一亮，原本一直明示暗示我們 MIS 伙伴可以買這個，但沒想到那傢伙不知道是怕麻煩還是懶得看，還是買了很多 7480 進來，一直到最近公司的 NB 汰換週期又到了，才有這個機會碰到這台，原本下單的是 7380 ，但運氣不錯的剛好遇到 Dell 改版，所以拿到手的就變成 7390 嘍。

01

IMAG2379

一樣是超簡潔的包裝，反正這種箱子留在公司也是佔地方。

IMAG2380

附贈的還是 65W 的充電器，雖然我喜歡他的大頭，因為和以前的可以相容，但 New XPS 13 可以用比較小巧的 45W 充電器，沒理由沒獨顯的 Latitude 不能用吧？

打開來驗明一下正身，背後的標籤的確是寫著 7390，只是，整台機器和我的 7280 怎麼看起來一樣？

IMAG2383

打開來看就發現不一樣的地方了，窄邊框！！！

IMAG2384

近一點看，感覺上方為了要保留視訊鏡頭，上方那個框的間距並不是很窄，和左右兩邊的差距有點大，感覺不是挺搭，難怪 New XPS 13 要把鏡頭往下方擺，既使被人笑說是照鼻孔。唉，有一好沒兩好。

IMAG2385IMAG2386

左右兩邊的 I/O，其實和 7280 一模一樣

04

上方是我的 7280 (指紋很多傷眼請見諒)，下方是 7390

05

左 7280，右 7390

06

左 7280，右 7390，其實可以看得出來這兩台除了螢幕之外，其餘的外觀是完全的一樣，但神奇的是，7390 (7380也是)官方的重量是 1.17kg，而 7280 則是 1.18kg，這和我與幾位同事實地手持的手感一致，就是 7390 的確是輕了一點點。

IMAG2391

最後一張就讓我把傳統邊框的 7280 和窄邊框的 7390 放在一起對照一下，有感覺大一點嗎？從訂價看窄邊框的代價是 100 鎂，我個人覺得是很值得，也推薦給網友參考。

 

PQI Smart 41W i-Charger PD 充電器開箱

今天為什麼特別要來寫這一篇看似葉佩雯的開箱呢？ 因為自從我之前入手了 New XPS 13 開始，就一直想找個 Type C with PD 的多埠充電器，這樣子不管是在外移動或是出差時，包包裡就可以少一個充電器的重量，然而之前只看過 PowerPort+ 5 USB-C PD 充電器，212g 左右的重量比我主力使用的 Acbel 萬用筆電充電器 229g 沒輕太多，還比我另一顆 Amacrox Uone 的 165g (含線) 還重，加上我一般狀況下也用不到  5 port 來充電，所以就遲遲未入手。一直到前幾天看到這顆東西：

2018-03-22 13.00.02

3 port，131g 的重量，價格也 OK (蝦皮上有不到 1,000 含運的)，過了幾天後這東西就到了我桌上了，包裝上寫這東西總輸出可以到是 41W，其中 Type C 的輸出最高 14.5V 2A = 29W，剩下兩個 USB Type A 輸出總和是 5V 2.4A = 12W，看來是剛好堪用。

2018-03-22 13.00.34

內容物很簡單就是一顆白豆腐，連一條線都沒附，幸好我之前就買了條紫米的雙 Type C 充電傳輸線，但這也表示這顆白豆腐就重 131g 了。

上面的標籤寫的是 PQI Japan 株式會社在中國生產的 (PQI 不是台灣公司嗎？)，查了一下日本的牌價是 3,980 日圓，所以我買的價格還好。不過這顆充電器的做工有點差強人意，我認為還比小米的 4 Port 充電器質感還差一點，四周斜邊摸起來略為割手，但不到會割傷的程度，那些標註規格的小字看起來也有一點點蓋歪。不過比較重要的安規倒是印了五種，雖然廣告上不像一些他廠一樣寫了什麼幾種保護，xx 晶片之類的，有通過五種安規倒是比較實際些。

單充電器的重量用我的廚房秤量出來是 135g，比規格上的 131g 多了 4g，有可能是這秤不準。加上 Type C 線材後則是 168g，比我之前買的 Amacrox Uone 還多了 3g 讓我有點小失望。但想想這可是能讓我少帶一顆充電器的好物時，就覺得這 3g 還 OK 了。

2018-03-22 13.04.36

配上號稱能走 3A 電流的 150cm 紫米傳輸充電線，和 Macbook 充電器一樣會干涉這種垂直多孔插座的其它插座孔…

2018-03-22_130757

我的 Dell E7280 竟然給我跳出這個訊息，說只有 35W 以上的供電才能保證一定往電池充，這點我還挺納悶，之前插過 QC 2.0 充電器時系統是跳出要 27W 所以不能用，而現在則是說要 35W，不過用了一下之後發現 Windows 右下角仍然顯示充電中，事後我也嘗試完全關機，他也的確充得進去，所以這顆充電器在一般出差或外出時小用還是可以的，但是要長時間在外執行重量級的程式時得要擔心力有未歹了。另外要補充的一點是，差著這顆充電器開機時，E7280 的 Bios 還會再給一個警告訊息，告訴你這個充電器不合 35W 的規，邊用邊充到時候越用電量越低的話你可別怪我沒通知你之類的意思 blah blah…..

2018-03-22 13.06.12

拿同一條 Type C 線來充我的 HTC U11 手機時，會顯示「已連接快速充電器」，雖然規格中這顆是沒有支援 QC 2.0 or 3.0 的，由於我手上也沒有偵測電量的測試器，所以也不清楚這個快速是跑在哪一檔 (這顆支援三種 PD 輸出：5V/3A ,9V/3A ,14.5V/2A) ，看網友有跑在 9V 過，而且沒聽過哪支手機能用 14.5V 這麼大的電壓充，所以只能不負責任推測是跑 9V 在充電。

後來也拿去充看看同事的 Macbook Pro 13 with TB，雖然沒截圖但是 Mac 上是顯示充電中的，大家也都知道 Macbook (12吋那台) 就是吃 29W 的充電器，但 Macbook Pro 13 標配的充電器則是 61W，想來也是只能期望帶著這顆充電器不會遇到要長時間跑程式的狀況了。

現在我正好插著這顆充電器對我開機著的 7280 充電中，目前電池仍有 92% 的電，但系統預估要 1hr 31mins 才能充飽，當然目前 Dell 的 Power Manager 因為判定有接充電器所以系統是跑在 Better Performance 模式下，各位看官可以自己參考一下這顆到底適不適合你入手了。

  • 補充說明一下，剛打完要 1hr 31mins 充飽電這一點，當我發表文章時卻發現 7280 的電池已經充飽了，實際上 Dell Power Manager 判定要 1 小時半的，但實際上 10 分鐘就把那 8% 充完畢了。
  • 剛剛看還有顆 Innergie PowerJoy 30C 的才 96g，但只提供 2 port，也許網友也會有興趣

Project Honolulu 是個免錢又大碗的東西嗎?

前幾週聽了 Weithenn 大介紹的 Windows S2D 和 Docker 之後，對於他提到的微軟免費工具 – Project Honolulu 很感興趣，聽來是號稱 MS System Center 的免費版本，這立刻讓我腦海中想到了諸如自動化升級、VM服務自助化或是什麼工作流程自動化一類的，心裡想說微軟終於是佛心來著，便馬上填了些資料下載來玩。

下載和安裝本身並不複雜，雖然它有三種部署的方式，但由於我的目的只是看看這東西有什麼功能，所以變直接安裝在我的 Windows 10 NB 上，這部分的安裝過程沒什麼困難性，一下子也就完成了。

倒是準備要被 Project Honolulu 「管控」的機器還有些特殊需求，除了至少要是 Windows 2012 R2 以上的版本外，還得裝上 Windows Management Framework (WMF) 5.0 以上的版本(網站上給的安裝連結是 WMF 5.1)，由於安裝完畢之後需要重開機，如果你的環境剛好沒有符合需求的機器，又不能輕易重開機的話，可能會跑不下去。安裝 WMF 5.1 的時候有個小插曲，就是我找了三台 Windows 2012 R2 ，每一台都告訴我這個安裝檔並不試用於我的環境，最後搞了老半天，原來我一直下載到的是一個叫做 W2K12-KB3191565-x64.msu 的安裝檔，但試用於 Windows 2012 R2 的安裝檔是叫做 Win8.1AndW2K12R2-KB3191564-x64.msu，這種蠢事我也是 Google 之後才發現的，顯然微軟這種命名方式騙到我這種蠢蛋了…

Project Honolulu 會在本機裡裝個小型的 Web server ，裝好之後直接點開始功能表就會把網頁給打開了，一打開來，我優先去點擊的這個功能：

01

嗯，Windows Update，怎麼這麼熟悉？ 按下 Install Updates 按鈕之後跳到下個頁面：

02

嗯… 還是很熟悉的畫面… 什麼？！ 這該不會就是 Project Honolulu 的功能吧？ 完整的把本機上的系統管理功能、設定功能給搬到 Web 上讓我們可以「遠端 GUI」作業，真的是這樣子嗎？讓我再擷取幾個畫面看看：

03
這是我自己 NB 的監控畫面，這… 不就是工作管理員

04
看得出來可以管理四種標的，後面的 Faliover Cluster 和 Hyper-Converged Cluster 我目前沒有，選個 Server Manager 看看：

05
要檢視某一台 Server 之前，要先等系統跑一下子

06.jpg設定畫面，原本以為可以在這裡設定報警條件的，結果原來只能設定環境變數

07.jpgEvent viewer ？！ 事件檢視器，一模一樣勒

08.jpg
防火牆設定，就是防火牆設定

09.jpg這個稍微有新意一點，Web 版本的遠端 Power Shell，有了這個就表示什麼功能都可以自己刻了吧？

10
放大絕了啦，Web 版的遠端桌面，Project Honolulu 還有什麼做不到的？

唯一的一點點小缺憾是目前沒有在 Project Honolulu 裡看到 IIS Management 的操作功能，不知道是還在製作中或是沒打算做(反正 Power Shell 都可以做到)，除了 IIS 之外，其實還有許多 Windows Server 的管理功能沒有被實做上去，這篇 FAQ 裡有完整的支援/不支援清單。

所以簡單做個總結，Project Honolulu 像是個 Remote Desktop Manager + Computer Manager 的綜合升級版，其中一種部署方式是可以把 Server 部署在跳板機上，然後系統管理員便可以從真正的遠端透過瀏覽器進行系統管理。由於可以事先把受管理的 Server 清單建在系統上，機器多的時候要找也是方便了一點，所以要說是簡化了系統管理程序也未嘗不可啦，不過要說是像 System Center 一樣能簡化資料中心的管理嘛，倒是差了那麼一大截。唯一可以理解的是：Project Honolulu 所依賴的底層 WMP 5.1 應該已經可以含括到 Windows 系統管理的許多功能了，所以除了微軟自己的 System Center 之外，應該也可以期待會有 3rd party 開發出諸如自助化服務網站的功能出來，或是自己想辦法刻出來？

11.jpg
目前我使用的 TP 版本是 1711，雖然我也只是玩一玩試一試，但可以感覺得出來這東西並沒有明顯的狀況或當機之類的問題，應該可以算是很成熟的東西了，只是我之前對它的期望太高，試用之後不免有些空虛就是了。

又一個 Wifi AP 問題

由於老闆做興趣的公司多元化發展，所以跑去外地開了間旅館，一切都完工開張之後，就開始是我們的夢魘了，說是夢魘也算一半是自己造的業，當初在幫忙審弱電規格時，想說只是間不大的旅館，看到兩家廠商都提出用 DrayTek 的 Fat AP + 中央控管解決方案後，就覺得這東西可能還可以，也傻傻的以為負責統包的「廠商」會用心的幫忙解決一切的問題，結果… 廠商也就只是裝好而已，其它的也是能推就推，加上我們自己也不熟悉這個廠牌，中間的過程這邊就不抱怨了，在一步一步的試錯之後，我們今天又遇到一個麻煩事。

老闆說：那個那個 908 號房的訊號很差，無線網路還是很不好啊，到底解決了沒有？

幸好今天我們的小銳同事今天有過去開會，趕緊拿起電話急扣：快幫我去 908 號房試試，其實也幸好那房間現在沒住人，小銳同事開了門就跑進去看訊號強度。

報告報告，訊號看起來都還不錯哩，我手機上看來都有 3 格 (其實我不太確定他是拿什麼軟體看的，我腦補滿格是 5 格)。

小銳這個人其實在技術上也是挺細心的，一下子用 LINE 打給我做走動測試，一下子跑 SpeedTest，終於給了我一個 AHA ：我知道哪裡有問題了！就是這個角落，小銳說他一走到這，和我的 LINE 通話就會斷斷續續。靠，這種土炮測試竟然比那些什麼 Wifi 強度 App 要來得快速有效還自帶團隊合作感，趕快繼續土炮下去，ㄟㄟㄟ，那個小銳你就一邊重複念 1~10，一邊走動，我一有聽不到的的時候就叫你停，然後看是在幾號…

AP1

測著測著小銳就想到幾週前，由於飯店在遠方，我們靠飯店那些非 IT 專業的工作人員蒐集到的問題描述又很亂：有人說連不上網路，也有人說網路速度慢，所以我們便在不同的樓層上對 AP 做上不同的設定，希望下次再來時可以藉由這些實驗組對照出還剩下的問題。

小銳說，這個樓層就是有做 2.4G + 5G 的雙頻設定，而且開了所謂的 Band Steering 功能，AP 上對這個功能的描述是：當 5G 訊號夠強時，AP 會強迫客戶端從 2.4G 跳到 5G 去。

只是沒想到，這個 5G 訊號的穿透能力看來不甚好，既使「訊號上」看起來還可以，但實際上的傳輸就是會出問題，嗯… 至少我們打 LINE 電話就出問題了。有了這個假設之後，我們就趕緊把這層樓的 5G 實驗組給拿掉，讓他只跑 2.4G 訊號，接著再讓小銳出動進行走動式土炮 LINE 通話測試，果不其然，一切就順順利利，趕快和老闆回報問題解決。

說實在的，對於 Wifi 問題我還真的沒啥辦法，又不是程式、系統或資料庫可以去翻出來看，訊號的這東西我是完全沒輒，你去問所謂的專家嘛，感覺就是叫你買 Cisco, Aruba 好像一切就解決了，你一叫他保證時他也不敢掛保證。這次大概是我處理各種 Wifi 問題以來「相對」的最有科學根據的一次吧，希望這樣子的運氣可以持續下去啊，不然三不五時的要開車跑遠地去處理也是既費時又費力。

Unifi AP 的升級

先開宗明義來說，其實不是什麼很難的東西，大致上來說，對於這類 ThinAP 的管理上，你得要注意 Controller 和 AP 之間誰負責什麼東西，才會比較容易知道問題出在哪。

1

以我今天遇到的問題來說，其實就只單純的是看到 Controller 的 GUI 上顯示了有 firmware 可以升級，按下升級鍵之後，這個 Controller 的 GUI 也是煞有其事的在那裡跑了很久，最後… 版本號碼還是顯示一樣，這問題與其說是今天發現的，倒不如說是已經發現很久了，只是之前一直沒有動機去升級它，今天是因為看到有幾位 user 反應有 Wifi 的連線問題，想說目前的版號距離上一次也已經快一年了，看 Change log 裡也滿滿的都是我看不懂的 bug fix，所以選日不如撞日，就試著解解看吧。

爬了一些論壇文章，症狀雖然都是升級不上去，但是有人教你用 GUI 上的自定義升級，有人教你 ssh 進 AP 自己下指令去 Controller 抓 firmware 下來，我甚至還跑到 AP 裡頭去看 log，但是都沒用，連 log 都沒看到任何錯誤。最後我是看到有個人提醒說要在 AP 上校時，這時候心血來朝，試著去 AP 上 ping ping 看隨便一個網址… Bingo！

原來是因為我們的 AP 由於是跑單純的 bridge mode，Controller 與 AP 之間的溝通也是透過 IP 而非 Domain name，所以當初設定的同事並沒有在 AP 上設定 DNS resolver，動手加進去之後，就可以順利由 GUI 上簡單的升級了。

2

在這個案例中，有趣的是由於 Controller 上一直顯示著可以升級 firmware，以致於我從沒想過實際的升級程序是 Controller 叫 AP 自己去抓 firmware 下來升級，加上這個 Controller 的 GUI 上也沒有正確 capture 這個錯誤出來，所以自己卡關了很久。這個升級雖然只是個不起眼的小事，卻解決了我心中卡很久的一口痰，還是覺得爽。

比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞， 才發現原來這東西這麼神，2700 倍的傳輸率，佇列延遲減少 25 倍，隨手翻了下網路上的部落格，沒想到有那麼浮誇的說法證明：下載從 84K/s 變成 3.9M/s，這立刻引起我的好奇心，找到了 Google 自己的部落格說明，原來是長久以來使用的 TCP 壅塞控制演算法有點笨，遇到有 packet loss 的狀況時，就會以比較保守的方式來傳遞接下來的封包，而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題，整個示意圖就如下所示：


* Source

文中也特別拿了幾個國家為例子，說明在應用了 TCP BBR 之後，YouTube 的表現情形，不看還好，一看之下，沒想到 Google 也這麼浮誇寫實，YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上，這讓我突然想到以前公司在進行某個網路直播專案時，那個爛 4G 網路讓我們驗收時吃了很多苦頭，所以我也來做個浮誇的測試好了。不過因為一來我很懶，二來也沒那個預算搭建回當初專案的原始架構，所以以下浮誇的測試只在我的本機上實驗。

  • 實驗環境 (都在同一台機器裡)：
NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome
  • 實驗方法：
  1. 先以 Kernel 2.6.32-696.6.3 直接測試，擷取螢幕看直播視訊延遲
  2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲，並隨機 drop 10% 的封包
  3. 等個幾秒，擷取螢幕看直播視訊延遲
  4. 停止 clumsy，等個幾秒，擷取螢幕看直播視訊延遲
  5. 升級 Kernel 為 4.13.0-0.rc1，重複步驟 1~4
    * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面，所以測試畫面中會看到 Firefox
  • 實驗結果：
  1. 沒 TCP BBR，不啟用 clumsy，延遲大概 3 秒
    Without BBR - normal network
  2. 沒 TCP BBR，啟用 clumsy，稍等一下，延遲變為 13 秒，實測時這個延遲會迅速擴大，最差的狀況是影像會停掉
    Without BBR - bad network
  3. 沒 TCP BBR，把 clumsy 關掉，稍等一下，延遲回到 5 秒左右
    Without BBR - normal network again
  4. 有 TCP BBR ，不啟用 clumsy，延遲大概 2-3 秒，其實和沒 BBR 時差不多，這畫面看起來延遲只有 2 秒應該只是個測試誤差
    With BBR - normal network
  5. 有 TCP BBR，啟用 clumsy，稍等一下，延遲變為 4 秒
    With BBR - bad network
  6. 不信邪，再等一等，有 TCP BBR，啟用 clumsy，延遲還是維持 4 秒左右
    With BBR - bad network-2
  7. 恢復原狀，有 TCP BBR，不啟用 clumsy，延遲還是維持 4 秒不動
    With BBR - normal network again

總結來看，這個 TCP BBR 還真的神，在高延遲且掉包的網路上，在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現，安裝的方法我就不特別提了，網路上隨便 google 都一堆，不過還是要提醒大家一下，再好的東西還是得先測試才能上正式環境，免得哪個不小心你就踩了坑了都不知道。

BBR Summary

一個很糟糕的 gmail 問題終於被修正了

認識我的人都知道，我在 gmail 一開始 beta 時就有幸拿到了邀請函，並且申請了一個和我英文名字一模一樣的 gmail 帳號，而我老婆的 gmail 帳號稍微差一點，有帶她的中文姓氏，我記得是因為當時 gmail 註冊的規則是不允許 5 個字以下 (含 5 個字) 的帳號名稱，且不能是常見的美國名字 (或單字，我猜)，而我的英文名字剛好是歐洲系的，所以一直以來我都對於能擁有這個帳號是爽在心理，偶而還拿出來炫耀一下。

但是事情總是不會那麼幸福美滿的，不知道從哪一天開始，我的 gmail 就充斥著一堆的垃圾信，講到這裡大家可能會覺得很怪，gmail 檔垃圾信不是出名的嗎？就算是我的 gmail 有個好名字，也沒有什麼關連性吧？

是的，gmail 的確是檔垃圾信檔得很好，但是，不是垃圾信的垃圾信呢？

啥，你在共啥小？！ 什麼叫不是垃圾信的垃圾信？

其實就是那種別人拿你的 gmail 帳號去註冊某個網路服務，之後那個服務就一直狂發信給你的一種狀況，根據我看了那麼多不是垃圾信的垃圾信的經驗得知，這種狀況一般可以歸類成兩種

  1. 真的是不小心寫錯 email 地址的：不管他是記姓不好的三寶、少根筋而打錯字還是管他阿媽什麼挖貴原因的，反正就是寫錯了，為啥我會知道是寫錯的呢？因為我有收到各種各國的 EC 網站送貨通知，而且錢都已經付了，在這裡還是要歌頌一下 Google，幸好他 gmail 內建有翻譯功能，不然我還真看不懂這些垃圾信
  2. 故意寫錯的：從這幾年收些垃圾信的經驗裡，還真的有很多網路服務是不驗證 email 信箱是不是你的 (請注意我現在已經是以全球性的世界觀來講這件事)，也就是你申請註冊之後，他就當你註冊成功了，所以有可能是有人亂用我的 gmail 帳號註冊，也不排除這是一種另類的廣告信手法。其實我猜 email 要認證這件事情應該是這幾年才有的，因為我的 Apple ID 其實早就被人申請好了，幾年前的某一天當我要申請 Apple ID 時，我做的事情其實是去按 forget password，而不是新申請一個，這類事情我至少經歷了三四次有吧，都是別人在多年前不流行 email 驗證時先幫我申請好的帳號，然後我再去用 forget password 給拿回來。而目前呢？剛剛翻了一下，我的信箱收件夾裡還躺著 4 封 Instagram 的申請確認信，其中 3 封是英文的，1 封是印尼文，當然我是個還沒用 Instagram 的土包子，這四封驗證信都不是我自己申請的。

那上面這些講了落落長，都不是 gmail 的糟糕問題啊？你到底在講啥？！

其實是 gmail 有個功能叫「備用信箱」，每個帳號都可以設定一個備用信箱，一旦你忘記自己信箱的密碼時，又沒有設定手機門耗時，就可以記封忘記密碼的信到你設定的備用信箱來進行重置密碼的動作。但是… gmail 這功能以前可是不需要驗證的，所以你設定了就是設定了，他也不會管你是不是有打錯字還是記錯了，所以我長久以來，就是會收到各國語言的「密碼重置信」，這時候我就得記得去按「請把我的 gmail 信箱從那傢伙的備用信箱移除」，非常的惱人，一直到今天，gmail 終於做出了一個劃時代的更新(對我而言啦)：

2017-07-28_010342

靠你終於改了啊，雖然我的帳號還是常收到不明來由的垃圾信，但連 google 都發垃圾信給我我就很不爽，雖然我的 gmail 因容量還沒到上限沒付過錢，但我可是 Android 的愛好者，GCE 也付了幾次小錢，平常也讓你抓我的 GPS 資訊讓你偵測車流量，終於，這次你解決了我的一個困擾。

其實我猜測有類似問題的人應該也不少，例如我公司的 email 並不好記，但偶而也是有類似的垃圾信出現，我會猜測是一種另類的廣告信手法，真是希望那些垃圾信名單機構可以增加一種黑名單，就是當你這個網站拿 email 註冊而不需驗證時，提出證明就可以列入這個黑名單內，然後不管是 gmail 或自己管理的 email server 就可以設定拒絕這類網站寄出的信件，才能杜絕這些惱人的垃圾信。