PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   七嘴八舌異言堂 (https://www.pcdvd.com.tw/forumdisplay.php?f=12)
-   -   Read the fxxking RFC.... (https://www.pcdvd.com.tw/showthread.php?t=1137247)

anderson1127 2017-11-07 11:18 PM

鵝大

您沒必要幫L4 switch的後端server的回應去做任何的模糊化回應吧??

所謂的L4 switch 只有去更動source IP , 不會去更動Layer 7的內容的!!

您說的mail server回應代碼,已經算是Layer 7的範圍 , 與Layer 4 無關喔!!

基本上,為避免責任問題,網路設備商不會去動Layer 7的內容,除非必要頂多就是copy一份內容!!

所以,後端的mail server怎麼回Client,L4 switch就直接轉送出去就好,不是嗎??

冰的啦魔王大人 2017-11-08 12:51 AM

既然這裡有RFC 大師,那就來問一下,
RFC 記載的技術,到底有沒有智財權的問題呀?
一般人可以拿去商業應用嗎?

cmwang 2017-11-08 07:51 AM

引用:
作者anderson1127
鵝大

您沒必要幫L4 switch的後端server的回應去做任何的模糊化回應吧??

所謂的L4 switch 只有去更動source IP , 不會去更動Layer 7的內容的!!


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

引用:
作者冰的啦魔王大人
既然這裡有RFC 大師,那就來問一下,
RFC 記載的技術,到底有沒有智財權的問題呀?
一般人可以拿去商業應用嗎?


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

野口隆史 2017-11-08 09:33 AM

引用:
作者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:flash: ),就跑來盧鵝,這不是滑天下之大稽嗎----鵝又不是那個廠商肚子裡的迴蟲,哪有辦法代替其回答啊,到頭來還不是只能按RFC給個一般性的回答而已,根本是在浪費鵝的時間:mad::mad:....

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鵝也沒搞清楚過:laugh: )....



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

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

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

anderson1127 2017-11-08 10:44 AM

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


原來您在說的是那 5 Layer Network Model , 但不管怎麼說 mail server還在第五層的Application layer 運作
無法干涉Transport Layer (L4) 運作 !!

話說回來,我自己也沒搞得很清楚OSI的session layer & presentation layer 給弄清楚過!!
尤其是那個session layer ....

網路設備裡的session , 我到目前為止 , 都還是用source ip & port <--> destination ip & port (TCP / UDP )
來當做一個session link !! :ase :ase :ase

TrueAkuma 2017-11-09 01:24 AM

引用:
作者devi
以前做台電的工程,契約所附的電纜線要求,引用ASTM規範,居然要求要附上ASTM規範檔,不接受英文,還要翻譯成中文 :jolin:

一開始不爽只附上英文版,還不給他標重點在哪裡。我說契約沒有要求要附中文版。
後來迫於無奈,還是找了翻譯社把重點頁翻譯成中文。
真不知道那些承辦以前是怎麼驗的…


因為以前的承辦調走了,你遇到的是新接手的

台電就是這種奇怪的文化,要大家一直輪調

說好聽是大家都會,但實際上根本不管你會不會就調過來,也不一定會有交接

cmwang 2017-11-09 06:43 AM

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

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


先感謝您的指教,不過這就牽涉到理想跟現實的差異了,雖然IANA有提供Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry,但除非是非常明確而且非常common的DSN,您確定不同公司的不同設備傳回同一個DSN時,其意涵真的是一模一樣的嗎:confused:....

引用:
作者野口隆史
要動的話不是應該是去問管mail server的人嗎?
主管不懂,也該告訴他找錯人處理


鵝當然回答承辦說絕大部份透過Internet提供的service都是依據RFC來的(RFC可以說是業界標準吧:flash: ),至於別人家的設備為什麼要回某個DSN鵝自然是無從置喙的,但是新老闆不接受這個說法,結果就變成承辦在兩天內盧鵝1x次了:mad:....

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


再次感謝您的指教,鵝當然知道RFC跟GPL是不一樣的東西,但是RFC是人寫的,除非RFC有白紙黑字要求列入RFC的東西一律都視為Public Domain,或是非常早期接受DARPA資助的成果(當時的學術單位應該不至於玩埋地雷的遊戲吧:o),IETF也是一大群人的組合,您能確定不會有類似Rxxxxs把自家的IP放在JEDEC定義的業界標準內,然後再來主張說只要有用到這個標準的人就得付xx費的狀況嗎----這就是理想和現實的差異了:stupefy::stupefy:....

cmwang 2017-11-09 06:55 PM

2個附加檔案
n年前PIX FW的feature不處理掉,反倒是下級單位(包括倒楣的承商)要自己想辦法,不知能不能用官大學問大形容啊:ase:ase....


所有的時間均為GMT +8。 現在的時間是04:00 PM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。