整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
子郵件協(xié)議中POP3協(xié)議用于接收郵件，SMTP協(xié)議用于發(fā)送郵件。SMTP的全稱為Simple Mail Transfer Protocol，也就是簡單郵件傳輸協(xié)議，字如其名。
相較于POP3而言，SMTP確實(shí)比較簡單。這里的簡單并不是指SMTP的命令比POP3少，而是指SMTP的命令是有序的，而POP3的命令是無序的，理解這一點(diǎn)很重要。也就是說SMTP的命令是要組合在一起才能完成一次郵件發(fā)送任務(wù)，單獨(dú)調(diào)用每個命令的意義不大。POP3命令則不同，LIST、STAT、UIDL、TOP、RETR、DELE等命令都可以獨(dú)立使用，比如用LIST命令查看郵件清單，然后用RETR命令接收郵件。
簡單的另一層含義是：就socket編程而言實(shí)現(xiàn)發(fā)送數(shù)據(jù)要比實(shí)現(xiàn)接收數(shù)據(jù)簡單點(diǎn)。
比如接收數(shù)據(jù)時要判斷數(shù)據(jù)是否接收完畢。如果一條數(shù)據(jù)以回車換行結(jié)束，就需要判斷是否接收到了"\r\n"，從而確保讀取到一條完整的消息體。而發(fā)送數(shù)據(jù)則不需要考慮上述問題，你可以按照自己的節(jié)奏發(fā)送數(shù)據(jù)，可以一次將整個消息體發(fā)送出去，也可以不用考慮服務(wù)器的死活一個字節(jié)一個字節(jié)發(fā)送數(shù)據(jù)，直至將整條消息發(fā)送完畢。
換句話說，接收數(shù)據(jù)要以流的方式進(jìn)行，而不是簡單的開辟一個緩沖區(qū)，進(jìn)行一次recv操作。 雖然大部分情況下這種方式也沒有問題，比如寫個Demo程序，但如果要讓你的網(wǎng)絡(luò)程序非常健壯的話，最好以流的方式進(jìn)行讀取。因?yàn)椴⒉皇敲看螌Ψ蕉紩凑漳闫谕姆绞桨l(fā)送數(shù)據(jù)給你，比如，你開辟了1024字節(jié)緩沖區(qū)用于接收網(wǎng)絡(luò)數(shù)據(jù)，但對方可能一次只給你發(fā)送一個字節(jié)，或者發(fā)出了1025個字節(jié)。
SMTP和HTTP協(xié)議一樣都屬于請求應(yīng)答式協(xié)議，也就是一問一答，客戶端發(fā)送命令后，服務(wù)器返回響應(yīng)內(nèi)容。 SMTP的響應(yīng)格式和HTTP協(xié)議的基本一樣，都是響應(yīng)碼+響應(yīng)描述。響應(yīng)碼用三位數(shù)字表示，空格后則是響應(yīng)信息的描述，只是HTTP協(xié)議會多一個版本信息。
這種一問一答式協(xié)議，在HTTP協(xié)議上體現(xiàn)的并不是很明顯，只有HTTP連接設(shè)置為Keep-Alive時，你才有機(jī)會使用GET或POST命令反復(fù)與服務(wù)器進(jìn)行交互，否則只有一次問答的機(jī)會。
但在SMTP協(xié)議下這種一問一答的交互方式就非常明顯了。 主要原因是完成一次郵件的發(fā)送任務(wù)涉及到的步驟比較多，我把電子郵件的發(fā)送分為如下五個步驟：
1、建立會話；
2、身份認(rèn)證；
3、發(fā)送郵件信封（發(fā)件人和收件人）；
4、發(fā)送郵件內(nèi)容（郵件正文和附件）；
5、關(guān)閉會話；
SMTP的命令主要就分布在這五個步驟中。下面以網(wǎng)易的yeah郵箱（smtp.yeah.net服務(wù)器）為例，具體說明這五個步驟的實(shí)現(xiàn)。C代表客戶端，S代表服務(wù)端。
SMTP命令：HELO
該階段用于建立客戶端與SMTP服務(wù)器的連接，在此基礎(chǔ)上，雙方進(jìn)行友好的問候。SMTP服務(wù)器的默認(rèn)端口號是25，如果是支持SSL協(xié)議，則默認(rèn)端口號是465。如果采用的是STARTTLS協(xié)議，則默認(rèn)端口是587，所謂的STARTSSL其實(shí)就是SSL協(xié)議，只是開始會話前雙方客套一下，問一下對方你還支持SSL啊？
連接建立后，服務(wù)器會發(fā)送一條歡迎語。接著你就需要問候一下服務(wù)器，并帶上你的機(jī)器的名稱。如下：
S: 220 yeah.net Anti-spam GT for Coremail System (yeah[20141016])
C: HELO your-computer-name
S: 250 OK
SMTP命令：AUTH LOGIN
該命令用于進(jìn)行身份驗(yàn)證，雖然這一步在SMTP協(xié)議中不是強(qiáng)制的要求，但目前幾乎所有的SMTP服務(wù)器都需要進(jìn)行身份認(rèn)證。增加這一步可以大大減少垃圾郵件的存在，以及避免有人偽造其它發(fā)件人進(jìn)行郵件的發(fā)送操作。
這一步中賬號和密碼需要進(jìn)行base64編碼，包括服務(wù)器發(fā)來的提示信息也是base64編碼。
首先發(fā)送AUTH LOGIN命令，服務(wù)器會返回“334 XNlcm5hbWU6”，“dXNlcm5hbWU6”解碼后為“username:”
UGFzc3dvcmQ6解碼為"Password:"
也就是提示用戶輸入用戶名和密碼。認(rèn)證成功后返回235，注意返回的不是二百五（250）哦。 接著根據(jù)服務(wù)器返回的提示，發(fā)送賬號（發(fā)件人的郵箱賬號）和密碼。
C: AUTH LOGIN
S: 334 dXNlcm5hbWU6
C: base64編碼后的賬號（發(fā)件人的郵箱賬號）
S: 334 UGFzc3dvcmQ6
C: base64編碼后的密碼
S: 235 Authentication successful
至于為何是base64編碼，可能是SMTP協(xié)議設(shè)計(jì)時考慮到用戶名和密碼的重要性，所采用的最簡單的“加密”手段。雖然base64只是編碼方式，不是加密方式，但在早期控制臺輸入命令的情況下，別人還是一下無法像記住明文一樣記住這些無規(guī)律的base64編碼。不過隨著SSL的應(yīng)用，這些都已不重要了。
SMTP命令：MAIL FROM、RCPT TO
該階段是告訴服務(wù)器發(fā)件人和收件人的郵箱地址，可以把這個階段想象為你在寫紙質(zhì)信件的信封。MAIL FROM用于指定發(fā)件人郵箱，該郵箱地址其實(shí)就是上述身份認(rèn)證中的賬號，如：
MAIL FROM: <lig4961@yeah.net>
RCPT TO用于指定收件人郵箱，一次只能指定一個收件人地址，如果收件人有多個的話，可以多次發(fā)送RCPT TO命令。
C: MAIL FROM: <lig4961@yeah.net>
S: 250 Mail OK
C: RCPT TO: <syfzxm@163.com>
S: 250 Mail OK
C: RCPT TO: <lig4961@yeah.net>
S: 250 Mail OK
注意，郵件地址要用放入<>中，此外，每條命令發(fā)送完畢后，一定要判斷服務(wù)器返回碼是否是250。 如果返回的不是二百五，說明你發(fā)送的地址可能是二百五，也就是不正確的地址，比如郵件地址中沒有@，或者在同一個郵箱系統(tǒng)中，SMTP服務(wù)器發(fā)現(xiàn)收件人的地址并不存在，也就是沒有注冊過。
看到這里可能有人會有疑問：我們通過郵件客戶端或網(wǎng)頁寫郵件時，不是有三種身份的收件人么？即：主送人（to）、抄送人（cc）、密送人（bcc）。是否存在RCPT CC和RCPT BCC命令，用于發(fā)送抄送人和密送人的郵箱地址呢？很遺憾，沒有這兩個命令。也就是說抄送人（cc）和密送人（bcc），也是通過RCPT TO命令進(jìn)行發(fā)送。
既然發(fā)送時不區(qū)分，那么我們在收到的郵件中怎么還能看到主送人和抄送人呢？或者說如何做到讓密送人在收到的郵件中看不見的。答案在下面郵件內(nèi)容中。
SMTP命令：DATA
這一步是發(fā)送數(shù)據(jù)最多也是最復(fù)雜的一步，但操作命令卻只有一個，就是DATA，也就是數(shù)據(jù)（郵件內(nèi)容），郵件內(nèi)容主要包括三個部分（可能會有內(nèi)嵌資源文件，也可以理解為狹義上的附件）：
1、郵件頭；
2、郵件正文；
3、郵件附件；
DATA命令發(fā)送后，服務(wù)器會返回354響應(yīng)碼，并告訴客戶端，數(shù)據(jù)結(jié)束要以"\r\n.\r\n"來標(biāo)識。接下來客戶端就可以發(fā)送整個郵件內(nèi)容了。
DATA
354 End data with <CR><LF>.<CR><LF>
SUBJECT:=?UTF-8?B?5p2l6IeqU29mdGxlZe+8jOi/meaYr+S4gOWwgea1i+ivlemCruS7tg==?=FROM: <lig4961@yeah.net>
TO: 'softlee1' <syfzxm@163.com>, 'softlee2' <lig4961@yeah.net>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=NextPart_SOFTLEE_Mail_E0B1A829CB1D4f55A037AE04B6A72078"
--=NextPart_SOFTLEE_Mail_E0B1A829CB1D4f55A037AE04B6A72078
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs
Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h
bC5kdGQiPg0KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPg0KDQo8
aGVhZD4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQv
郵件內(nèi)容的格式目前基本都采用MIME格式，MIME格式比較簡單，可參見文章：《如何解析EML（郵件）格式的文件以及一款小巧的EML郵件閱讀工具》。
這里我們不具體介紹如何編碼郵件正文和附件。主要介紹郵件頭中的信息，主題（Subject）、發(fā)件人（From）、收件人（To）、抄送（Cc）。我們看查看郵件時，讀到的主題、收件人和抄送人就來自于上述字段。這里收件人和抄送人僅作為郵件頭的一部分進(jìn)行展現(xiàn)，服務(wù)器并不會關(guān)心這些地址是否真實(shí)存在，或者說服務(wù)器并不關(guān)心這些地址是否跟使用RCPT TO命令發(fā)送的地址保持一致。回到第三階段中最后的幾個問題，我們可以通過郵件頭來展現(xiàn)該郵件的抄送人是誰，并且將密送人隱藏掉。當(dāng)然你也可以篡改上述信息，比如隱瞞某些收件人，或者將密送人也一并展現(xiàn)。
郵件正文和附件的編碼可參照MIME格式的文章。最后所有數(shù)據(jù)發(fā)送完畢后，一定要發(fā)送"\r\n.\r\n"，從而告訴SMTP服務(wù)器所有數(shù)據(jù)發(fā)送完畢。
SMTP命令：QUIT
這一步非常簡單，就是發(fā)送一條QUIT命令，QUIT命令發(fā)送完畢后，還是要判斷服務(wù)器的返回碼是否為250。如果返回的不是，則表明發(fā)送失敗，SMTP服務(wù)器可能不會將郵件轉(zhuǎn)發(fā)到收件人所在的郵箱中，這一點(diǎn)很重要。
至此，整個SMTP協(xié)議介紹完畢。SMTP協(xié)議比較簡單，但具體的實(shí)現(xiàn)細(xì)節(jié)可能還有很多，需要在實(shí)踐中去體驗(yàn)，有的服務(wù)器返回消息體是多行的，比如outlook郵箱的服務(wù)器，下面是outlook郵箱使用STARTTLS協(xié)議截圖：
附一： SMTP郵件發(fā)送工具
該工具特點(diǎn)：
1、基于命令行方式且只有一個獨(dú)立文件；
2、支持SSL、STARTSSL協(xié)議；
3、具有豐富的命令行參數(shù)；
近被「諾亞財(cái)富34億踩雷」的新聞刷屏了，報案、否認(rèn)、甩鍋，一波三折，如今演繹成了羅生門。承興造假，京東否認(rèn)，諾亞報案。如何通過技術(shù)方案的設(shè)計(jì)在風(fēng)險發(fā)生時為業(yè)務(wù)提供強(qiáng)有力的舉證支持是我最近一直在思考的事情，其中電子合同的有效性是我們一直在討論的重點(diǎn)問題。
隨著互聯(lián)網(wǎng)金融/金融科技的發(fā)展，合同通過電子化簽署逐漸被大家接受。但是受限制于國內(nèi)《電子簽名法》采用了技術(shù)折中的立法模式，法律法規(guī)僅從功能性和效果上的角度上提出了要求。
如何界定電子簽名、數(shù)據(jù)電文及電子合同的有效性涉及較為復(fù)雜的技術(shù)知識，司法實(shí)踐中對于技術(shù)路徑審查的相關(guān)經(jīng)驗(yàn)并不多，存在著對“電子簽名制作數(shù)據(jù)”、“電子簽名”、“數(shù)字簽名”、“用戶密碼”等專業(yè)概念的認(rèn)知偏差，對如何簽出一份合法有效的電子合同則比較模糊。
針對于此，我也與很多的法務(wù)同學(xué)、電子合同服務(wù)商進(jìn)行過交流，整理了下我在交流中的感受，分享出來拋磚引玉，歡迎砸我。
首先我們得確認(rèn)電子合同是合法有效的，這是這篇文章的基礎(chǔ)。
對于這一點(diǎn)，在《合同法》以及《電子簽名法》中都有明確規(guī)定：
《中華人民共和國合同法》
第十條：當(dāng)事人訂立合同，有書面形式、口頭形式和其他形式；
第十一條：書面形式是指合同書、信件和數(shù)據(jù)電文（包括電報、電傳、傳真、電子數(shù)據(jù)交換和電子郵件）等可以有形地表現(xiàn)所載內(nèi)容的形式。
簡而言之：電子合同屬于合同的一種。
《中華人民共和國電子簽名法》
第十三條 電子簽名同時符合下列條件的，視為可靠的電子簽名：
- 電子簽名制作數(shù)據(jù)用于電子簽名時，屬于電子簽名人專有；
- 簽署時電子簽名制作數(shù)據(jù)僅由電子簽名人控制；
- 簽署后對電子簽名的任何改動能夠被發(fā)現(xiàn)；
- 簽署后對數(shù)據(jù)電文內(nèi)容和形式的任何改動能夠被發(fā)現(xiàn)。當(dāng)事人也可以選擇使用符合其約定的可靠的條件的電子簽名；
第十四條 可靠的電子簽名與手寫簽名或者蓋章具有同等的法律效力
簡而言之：《電子簽名法》規(guī)定了可靠的電子簽名的有效性以及可靠的電子簽名的要素：專有、專控、不可篡改。
（當(dāng)然，《電子簽名法》中也規(guī)定了一些不適用電子簽名的情況：涉及婚姻、收養(yǎng)、繼承等人身關(guān)系的；涉及停止供水、供電、供氣等公用事業(yè)服務(wù)的；法律、行政法規(guī)規(guī)定的不適用電子文書的其他情形。這些不在我們本次討論范圍之內(nèi)。）
合同的成立在傳統(tǒng)合同書中一般通過簽字或者蓋章的方式來體現(xiàn)，在電子合同中簽字蓋章的行為被可靠的電子簽名所代替《電子簽名法》第十四條[1]。
本質(zhì)上電子合同的成立生效沒有跳出傳統(tǒng)合同的要件要求，這些要求我們不在此做討論。
既然是「可靠的電子簽名」與手寫簽名或者蓋章具有同等的法律效力，那么我們只需要能在業(yè)務(wù)中能夠證明符合相關(guān)要素即可。市面上的一些第三方電子合同服務(wù)商都有符合相關(guān)規(guī)定（至少是能經(jīng)得起推敲）的產(chǎn)品方案（畢竟人家賺的就是這份錢）。
但第三方服務(wù)商的標(biāo)準(zhǔn)產(chǎn)品開發(fā)需要最大程度的降低其自身的風(fēng)險，一般情況下會將簽署合同的整個過程至于其可控范圍內(nèi)，其產(chǎn)品流程并不一定適合我們的業(yè)務(wù)系統(tǒng)交互需求甚至可能與業(yè)務(wù)系統(tǒng)相沖突。
因此部分過程需要業(yè)務(wù)系統(tǒng)自己完成，業(yè)務(wù)系統(tǒng)在風(fēng)險發(fā)生時需要承擔(dān)一定舉證責(zé)任（不得不說，某些服務(wù)商的方案對于業(yè)務(wù)系統(tǒng)侵入性太大，很難接受啊）。
我們先對電子合同簽署的生命流程進(jìn)行拆解：
實(shí)名認(rèn)證步驟，一般分為個人實(shí)名和企業(yè)實(shí)名。（不討論線下核驗(yàn)的方式）
個人實(shí)名的方案很多：生物識別、銀行卡驗(yàn)證、手機(jī)號實(shí)名認(rèn)證……一般目前最保險的是掃臉認(rèn)證活體檢測，最好將活體的視頻保存下來，以便舉證。
企業(yè)實(shí)名，目前用的最多的營業(yè)執(zhí)照、銀行賬戶小額打款、法人身份證來驗(yàn)證。
這里順便我說一句，我只看到一家供應(yīng)商可以提供法人姓名+身份證號的認(rèn)證信息，不知道市面上還有沒有其他的服務(wù)商可以有此類服務(wù)提供（不是根據(jù)法人身份證對信息做二要素驗(yàn)證，而是根據(jù)工商注冊信息對提供的法人姓名和身份證號做驗(yàn)證）。
意愿認(rèn)證上，方式有很多。目前大部分第三方電子合同服務(wù)商都采用云托管數(shù)字證書模式，在意愿認(rèn)證上針對個人一般采用短信驗(yàn)證碼、人臉識別等來作為簽署人意愿表達(dá)的行為；針對企業(yè)一般通過向企業(yè)授權(quán)人發(fā)送短信驗(yàn)證碼、識別授權(quán)人人臉等方式或者采用 Ukey 來作為意愿表達(dá)。
這里多說一句：如果你采用 ukey 來做鑒權(quán)，需要考慮一點(diǎn)就是簽署時使用的數(shù)字證書是否為 ukey 里存儲的數(shù)字證書。如果不是（極大概率不是）一定要注意證據(jù)鏈完整的問題，因?yàn)楸举|(zhì)上還是云托管數(shù)字證書來完成簽署。
至于合同生成和司法舉證，去找第三方服務(wù)商吧，如果這些事情都要自己做，那你就是自己在做一個電子合同平臺了。
其實(shí)技術(shù)上沒有難點(diǎn)，主要在舉證問題上有一些思考：
一般來說，我們做實(shí)名都是調(diào)用第三方數(shù)據(jù)接口，我們需要盡量保證調(diào)用記錄的完整性及可查性。在出現(xiàn)電子合同有效性問題時可以提供我方已經(jīng)進(jìn)行應(yīng)盡的實(shí)名義務(wù)，并在力所能及的范圍內(nèi)做到了對用戶的實(shí)名認(rèn)證。
針對企業(yè)實(shí)名，要至少核驗(yàn)包括包括企業(yè)名稱、統(tǒng)一社會信用代碼，最好對法人姓名及身份證號進(jìn)行核驗(yàn)，同時應(yīng)對經(jīng)辦人進(jìn)行個人實(shí)名核驗(yàn)，以及企業(yè)核心隱私數(shù)據(jù)的核驗(yàn)，例如對公銀行打款、開具指定金額發(fā)票等核驗(yàn)方式；
也可通過電子認(rèn)證服務(wù)機(jī)構(gòu)頒發(fā)的數(shù)字證書進(jìn)行實(shí)名核驗(yàn)（這一點(diǎn)某 CA 的一個服務(wù)可以實(shí)現(xiàn)通過全國大部分（小）銀行發(fā)放的 ukey進(jìn)行實(shí)名認(rèn)證，不過大行很少）。
這里需要注意的一點(diǎn)是我們在選擇第三方數(shù)據(jù)服務(wù)商的時候一定要主要選擇政府權(quán)威部門的數(shù)據(jù)庫或者取得政府權(quán)威部門授權(quán)或認(rèn)可的電子數(shù)據(jù)庫（比如國政通……國政通麻煩廣告費(fèi)結(jié)下）
在合法合規(guī)的前提下，除通過短信驗(yàn)證碼、人臉識別或 ukey 認(rèn)證等方式完成用戶意愿認(rèn)證外，管理系統(tǒng)還應(yīng)該盡可能的收集用戶在簽署時的IP 地址、操作設(shè)備 MAC 地址、操作系統(tǒng)信息等可以佐證是用戶自身操作的信息。
目前大部分系統(tǒng)對接第三方電子合同服務(wù)商的時候?yàn)榱瞬蛔岆娮雍贤到y(tǒng)侵入業(yè)務(wù)系統(tǒng)都采用了各家服務(wù)商提供的「自動簽署」方案（這一點(diǎn)我要吐槽下拉，各家差不多都有這樣的接口，但是在使用上并沒有很好的給用戶說明。）
首先，我們要說的是《電子簽名法》第十三條里提到的「簽署時電子簽名制作數(shù)據(jù)僅由電子簽名人控制」這一項(xiàng)規(guī)定是對電子簽名過程中電子簽名制作數(shù)據(jù)歸誰控制的要求。這里所規(guī)定的控制是指一種實(shí)質(zhì)上的控制，即基于電子簽名人的自由意志而對電子簽名制作數(shù)據(jù)的控制。
在電子簽名人實(shí)施電子簽名行為的過程中，無論是電子簽名人自己實(shí)施簽名行為，還是委托他人代為實(shí)施簽名行為，只要電子簽名人擁有實(shí)質(zhì)上的控制權(quán)，則其所實(shí)施的簽名行為，滿足本法此項(xiàng)規(guī)定的要求。（這段話不是我說的，是全國人大關(guān)于《電子簽名法》的釋法[2]）
在中國互聯(lián)網(wǎng)金融協(xié)會《互聯(lián)網(wǎng)金融個體網(wǎng)絡(luò)借貸電子合同安全規(guī)范（征求意見稿）》第 8 司法舉證要求（d）中也提到「電子簽名人委托他人代為實(shí)施簽名行為時，從業(yè)機(jī)構(gòu)或第三方電子合同訂立系統(tǒng)服務(wù)商提供電子簽名制作數(shù)據(jù)由電子簽名人控制的證據(jù)，包括調(diào)用電子簽名制作數(shù)據(jù)的時間和方式、電子簽名人位置、IP地址、授權(quán)及認(rèn)證方式、授權(quán)及認(rèn)證記錄等；」
所以，自動簽署的方案大家還是可以放心用，只需要你能通過其他方式來證明電子簽名人擁有實(shí)質(zhì)上的控制權(quán)即可。
關(guān)于電子簽名，有一個舉證的坑。
《電子簽名法》第二十八條：電子簽名人或者電子簽名依賴方因依據(jù)電子認(rèn)證服務(wù)提供者提供的電子簽名認(rèn)證服務(wù)從事民事活動遭受損失，電子認(rèn)證服務(wù)提供者不能證明自己無過錯的，承擔(dān)賠償責(zé)任。
也就是說，關(guān)于電子簽名，舉證責(zé)任倒置。即對方提出的侵權(quán)事實(shí)，電子認(rèn)證提供者如果予以否認(rèn)，則應(yīng)負(fù)舉證責(zé)任，證明自己沒有過錯。
在司法實(shí)踐上，《袁斌與合肥夢川玖貿(mào)易有限公司等小額借款合同糾紛二審案件》【案號：北京市第三中級人民法院（2018）京03民終4903號】[3]中，法院也是這樣認(rèn)定的。
當(dāng)然，只要電子認(rèn)證服務(wù)提供者能夠證明自己對于電子簽名人或者電子簽名依賴方所遭受的損失沒有過錯，就不承擔(dān)責(zé)任。而對于電子認(rèn)證服務(wù)提供者來講，只要能夠證明其所提供的服務(wù)完全是嚴(yán)格按照本法和符合國家規(guī)定并向國務(wù)院信息產(chǎn)業(yè)主管部門備案的電子認(rèn)證業(yè)務(wù)規(guī)則實(shí)施的，則應(yīng)能夠證明沒有過錯。（《電子簽名法釋義 法律責(zé)任》[4]）
電子簽名無效僅僅表示該電子簽名并非當(dāng)事人真實(shí)意愿的表達(dá)，并不必然影響當(dāng)事人之間的部分關(guān)系（比如債權(quán)債務(wù)關(guān)系、勞動關(guān)系）的成立。
如果能夠從其他方面來證明當(dāng)事人之間存在相關(guān)關(guān)系，法院大概率上會要求侵權(quán)方承擔(dān)民事責(zé)任。但一些合同上具體規(guī)定可能無法予以認(rèn)定。
比如上邊提到的《袁斌與合肥夢川玖貿(mào)易有限公司等小額借款合同糾紛二審案件》中，法院雖然認(rèn)定電子簽名無效，但是從實(shí)名認(rèn)證信息、操作記錄等方面認(rèn)定借款合同有效。
其實(shí)這一點(diǎn)上，《最高人民法院關(guān)于互聯(lián)網(wǎng)法院審理案件若干問題的規(guī)定》第十一條[5]已經(jīng)明確指出：「當(dāng)事人提交的電子數(shù)據(jù)，通過電子簽名、可信時間戳、哈希值校驗(yàn)、區(qū)塊鏈等證據(jù)收集、固定和防篡改的技術(shù)手段或者通過電子取證存證平臺認(rèn)證，能夠證明其真實(shí)性的，互聯(lián)網(wǎng)法院應(yīng)當(dāng)確認(rèn)。」
最后多說一句，如果有錢花一點(diǎn)錢找服務(wù)商做個證據(jù)保全系統(tǒng)或者直接和司法鑒定中心、公證處之類的合作，畢竟法官不是開發(fā)小哥，你跟他講技術(shù)遠(yuǎn)不如公證處或者司法鑒定中心的一個章子管用。
[1]《電子簽名法》第十四條:可靠的電子簽名與手寫簽名或者蓋章具有同等的法律效力。
[2]全國人大關(guān)于《電子簽名法》的釋法:http://t.cn/AiYEl4bm
[3]《袁斌與合肥夢川玖貿(mào)易有限公司等小額借款合同糾紛二審案件》【案號：北京市第三中級人民法院（2018）京03民終4903號】:http://t.cn/AiYEOrYd
[4]《電子簽名法釋義 法律責(zé)任》:http://t.cn/AiYElv5w
[5]《最高人民法院關(guān)于互聯(lián)網(wǎng)法院審理案件若干問題的規(guī)定》第十一條:http://www.court.gov.cn/zixun-xiangqing-116981.html
互金業(yè)務(wù)中經(jīng)常提到的電子合同，到底是個啥？
張小璋，公眾號：張小璋的碎碎念（ID：SylvainZhang），人人都是產(chǎn)品經(jīng)理專欄作家。野蠻生長的產(chǎn)品經(jīng)理，專注于互聯(lián)網(wǎng)金融領(lǐng)域。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于 CC0 協(xié)議
是案例解析 FileMaker 18 新功能的最后一篇，我們來聊一下用增強(qiáng)的“從 URL 插入”腳本來實(shí)現(xiàn)發(fā)送 HTML 郵件的功能。
發(fā)送郵件對于 FileMaker 來說并不是什么陌生功能，專門就有發(fā)送郵件這個腳本來操作。不過我們這里談的是帶排版的 HTML 郵件，這才是 FileMaker 18 新增的功能。這個功能的實(shí)現(xiàn)是因?yàn)椤皬?URL 插入”腳本新增支持：smb、smtp、smtps、ldap 和 ldaps。其中 smtp&smtps 就是發(fā)郵件的協(xié)議，前者為常規(guī)發(fā)件協(xié)議、后者為 SSL 加密的發(fā)件協(xié)議。比如，我們使用的 QQ 企業(yè)郵箱，就是通過 SSL 加密，所以必須使用 smtps 協(xié)議。
選定協(xié)議之后，我們還需要了解 cURL 發(fā)郵件的配置選項(xiàng)。這主要包括：
--mail-from：發(fā)件人郵箱
--mail-rcpt：收件人郵箱
--upload-file：包含發(fā)件人、收件人、標(biāo)題、郵件內(nèi)容的 txt 文件
--user：“發(fā)件郵箱:密碼”格式的用戶名和密碼
以上配置需要連接成一條文本，設(shè)置到“從 URL 插入”的“指定cURL 選項(xiàng)”。
需要特別注意的是 --upload-file 選項(xiàng)，這里是將發(fā)件人、收件人、標(biāo)題、郵件內(nèi)容合并成一個 txt 文本，并放置到容器中進(jìn)行調(diào)用。文本格式如下（Content-Type 和郵件內(nèi)容之間需要留 1 行以上空行）：
具備上面部分的知識后，我們來再看一下如何在 FileMaker 中實(shí)現(xiàn)。
我們主要會用的腳本就是“從 URL 插入”，它一共有 5 個配置項(xiàng)。
選擇全部內(nèi)容：這里是發(fā)送郵箱、不需要接收返回?cái)?shù)據(jù)，所以勾不勾都不影響
以上就是 FileMaker 18 發(fā) HTML 郵件的新功能。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
