瀏覽單個文章
野口隆史
Elite Member
 
野口隆史的大頭照
 

加入日期: Mar 2001
您的住址: Rivia
文章: 7,050
引用:
作者cmwang
不好意思,大家沒搞清楚鵝的重點,這跟幫不幫他翻譯一點關係都沒有,鵝的設備算是L4的proxy吧,之前是把server真正的return code模糊化回給client(除非server很明確回2xx,不然絕大部份是回4xx或5xx給client),新老闆要求不做模糊化鵝當然可以依照其指示處理,但是他問不動後端mail server廠商其return code定義到底是怎麼來的(RFC只定義大方向,2xx/4xx/5xx後面的x.y.z通常是vendor specific ),就跑來盧鵝,這不是滑天下之大稽嗎----鵝又不是那個廠商肚子裡的迴蟲,哪有辦法代替其回答啊,到頭來還不是只能按RFC給個一般性的回答而已,根本是在浪費鵝的時間....

DSN CODE的2xx/4xx/5xx後面的y.z怎麼會是廠商定義?
明明RFC都有寫了
https://tools.ietf.org/html/rfc3463#page-10

也許我見識不多,十幾年來還沒看過有廠商亂丟DSN CODE
話說DSN CODE之所以會是RFC標準
是因為他們是溝通協定,亂改這個通常只是搞死自己而已
看不到任何好處

另外為什麼L4 PROXY要做這種事情?
DSN CODE已經是包在message裡面了
要動的話不是應該是去問管mail server的人嗎?
主管不懂,也該告訴他找錯人處理

如果你要去置換那個DSN CODE,這不是搞死自己嗎?

如果從原始問題來看這個5.7.1
排除帳號認證錯誤的問題
這比較像是ANTI SPAM有問題,造成信件無法順利送達
應該是解決這個問題
怎麼會是往機器不能送出某些DSN CODE方向處裡?


引用:
作者cmwang
不好意思,鵝說的L4是指TCP/IP的L4,而非ISO的L7(老實說ISO的7 layers鵝也沒搞清楚過 )....



絕大部份RFC都是Public Domain(PD),除非原作者有聲明保留智慧財產權或要求另行授權,直接拿去做商業應用大至上不會有問題,但RFC並不像GNU有要求從GNU所衍生出來的object都必須遵守GNU的授權條款,所以像鵝被迫為某人畫重點這類狀況就難說了....

說錯了
拿GPL類比也不對
GPL是開放碼的通用授權協定
RFC定義的是通訊協定的標準流程
這兩個是不一樣的東西,規範的也是不一樣的東西

TCP/IP就是RFC標準,你可以修改它的運作方式
像以前3COM的一些所謂搶頻寬卡
就是自己修改溝通標準後的產物
因為在正常的TCP/IP的協定
是不可能有這種搶頻寬神卡出現的
__________________
Folding@home with GPGPU集中討論串

Unix Review: ArchLinuxSabayonOpenSolaris 2008.5Ubuntu 8.10
AVs Review: GDTCAntiVir SSESSKIS 09NIS 09Norton 360 V3

I Always Get What I Want.
舊 2017-11-08, 09:33 AM #14
回應時引用此文章
野口隆史離線中