ARC initial implementation. Experimental. Bug 2162
[exim.git] / test / scripts / 4560-ARC / 4560
1 # ARC verify and sign
2 #
3 exim -DSERVER=server -bd -oX PORT_D
4 ****
5 #
6 # We send this one through one forwarding hop.
7 # It starts off bare, so the forwarder reception gets an ARC status of "none".
8 # The outbound signs it with that, and the final receiver is happy to pass it.
9 #
10 client 127.0.0.1 PORT_D
11 ??? 220
12 HELO xxx
13 ??? 250
14 MAIL FROM:<CALLER@bloggs.com>
15 ??? 250
16 RCPT TO:<za@test.ex>
17 ??? 250
18 DATA
19 ??? 354
20 Subject: Test
21
22 This is a test body.
23 .
24 ??? 250
25 QUIT
26 ??? 221
27 ****
28 #
29 exim -DSERVER=server -DNOTDAEMON -q
30 ****
31 exim -DSERVER=server -DNOTDAEMON -q
32 ****
33 #
34 #
35 #
36 #
37 #
38 #
39 #
40 #
41 #
42 # We send this one through two forwarding hops.
43 # It starts off bare, so the 1st forwarder reception gets an ARC status of "none".
44 # The outbound signs it with that, and the 2nd forwarder is happy to pass it.
45 # The outbound signs again, and the final receiver is happy.
46 #
47 client 127.0.0.1 PORT_D
48 ??? 220
49 HELO xxx
50 ??? 250
51 MAIL FROM:<CALLER@bloggs.com>
52 ??? 250
53 RCPT TO:<zza@test.ex>
54 ??? 250
55 DATA
56 ??? 354
57 Subject: Test
58
59 This is a test body.
60 .
61 ??? 250
62 QUIT
63 ??? 221
64 ****
65 #
66 exim -DSERVER=server -DNOTDAEMON -q
67 ****
68 exim -DSERVER=server -DNOTDAEMON -q
69 ****
70 exim -DSERVER=server -DNOTDAEMON -q
71 ****
72 #
73 #
74 #
75 #
76 #
77 #
78 #
79 #
80 #
81 # We send this one through one forwarder, one mailinglist, and one more forwarder
82 #
83 client 127.0.0.1 PORT_D
84 ??? 220
85 HELO xxx
86 ??? 250
87 MAIL FROM:<CALLER@bloggs.com>
88 ??? 250
89 RCPT TO:<zmza@test.ex>
90 ??? 250
91 DATA
92 ??? 354
93 Subject: Test
94
95 This is a test body.
96 .
97 ??? 250
98 QUIT
99 ??? 221
100 ****
101 #
102 exim -DSERVER=server -DNOTDAEMON -q
103 ****
104 exim -DSERVER=server -DNOTDAEMON -q
105 ****
106 exim -DSERVER=server -DNOTDAEMON -q
107 ****
108 exim -DSERVER=server -DNOTDAEMON -q
109 ****
110 #
111 #
112 #
113 #
114 #
115 #
116 #
117 #
118 #
119 # We send this one through two forwarders, then one ARC-unaware mailinglist
120 # then one more forwarder
121 #
122 client 127.0.0.1 PORT_D
123 ??? 220
124 HELO xxx
125 ??? 250
126 MAIL FROM:<CALLER@bloggs.com>
127 ??? 250
128 RCPT TO:<zzmza@test.ex>
129 ??? 250
130 DATA
131 ??? 354
132 Subject: Test
133
134 This is a test body.
135 .
136 ??? 250
137 QUIT
138 ??? 221
139 ****
140 #
141 exim -DSERVER=server -DNOTDAEMON -q
142 ****
143 exim -DSERVER=server -DNOTDAEMON -q
144 ****
145 exim -DSERVER=server -DNOTDAEMON -DOPTION -q
146 ****
147 exim -DSERVER=server -DNOTDAEMON -q
148 ****
149 exim -DSERVER=server -DNOTDAEMON -q
150 ****
151 #
152 #
153 #
154 #
155 #
156 #
157 #
158 #
159 #
160 # We send this one through a forwarders, then an ARC-unaware forwarder
161 #
162 client 127.0.0.1 PORT_D
163 ??? 220
164 HELO xxx
165 ??? 250
166 MAIL FROM:<CALLER@bloggs.com>
167 ??? 250
168 RCPT TO:<zza@test.ex>
169 ??? 250
170 DATA
171 ??? 354
172 Subject: Test
173
174 This is a test body.
175 .
176 ??? 250
177 QUIT
178 ??? 221
179 ****
180 #
181 exim -DSERVER=server -DNOTDAEMON -q
182 ****
183 exim -DSERVER=server -DNOTDAEMON -DOPTION -q
184 ****
185 exim -DSERVER=server -DNOTDAEMON -q
186 ****
187 #
188 #
189 #
190 #
191 #
192 #
193 #
194 #
195 #
196 # We send this one through one forwarding hop.
197 # It starts with one ARC-set.
198 # The reception at the forwarder gets an ARC-fail, because the bodyhash does not
199 # match - so the forwarder outbound ARC-signs as a fail,
200 # and the final receiver evaluates ARC status as fail.
201 # Mail original in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11#page-14
202 #
203 client 127.0.0.1 PORT_D
204 ??? 220
205 HELO xxx
206 ??? 250
207 MAIL FROM:<CALLER@bloggs.com>
208 ??? 250
209 RCPT TO:<za@test.ex>
210 ??? 250
211 DATA
212 ??? 354
213 Received: from dragon.trusteddomain.org (localhost [127.0.0.1])
214 by dragon.trusteddomain.org (8.14.5/8.14.5) with ESMTP id w121YG2q036577;
215 Thu, 1 Feb 2018 17:34:20 -0800 (PST)
216 (envelope-from arc-discuss-bounces@dmarc.org)
217 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmarc.org;
218 s=clochette; t=1517535263;
219 bh=DXU/xKzzQYeoYB254nZ0AzNm7z2YZ//FpTnhgIjPyt8=;
220 h=Date:To:In-Reply-To:References:Cc:Subject:List-Id:
221 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
222 From:Reply-To;
223 b=Z66qes0GxyXtv0ow232KSy/b44fPNLZL8JOXHiJLi9dHzIPyxsQd/Zb5NP8i3427g
224 a9tEyo8Rpz8DPbn351e+IlYqRGLfokTWgX+7NfMLy87p3SfnPytUu6PM8QiW2VC889
225 Tk0K+5xH5KSgkENaPdLBigHtunyNZaSofgKy5vBM=
226 Authentication-Results: dragon.trusteddomain.org; sender-id=fail (NotPermitted) header.sender=arc-discuss-bounces@dmarc.org; spf=fail (NotPermitted) smtp.mfrom=arc-discuss-bounces@dmarc.org
227 Received: from mailhub.convivian.com (mailhub.convivian.com [72.5.31.108])
228 by dragon.trusteddomain.org (8.14.5/8.14.5) with ESMTP id w121YEt6036571
229 for <arc-discuss@dmarc.org>; Thu, 1 Feb 2018 17:34:14 -0800 (PST)
230 (envelope-from jered@convivian.com)
231 Authentication-Results: dragon.trusteddomain.org; dkim=pass
232 reason="1024-bit key"
233 header.d=convivian.com header.i=@convivian.com header.b=LHXEAl5e;
234 dkim-adsp=pass
235 Authentication-Results: dragon.trusteddomain.org;
236 sender-id=pass header.from=jered@convivian.com;
237 spf=pass smtp.mfrom=jered@convivian.com
238 Received: from zimbra8.internal.convivian.com (zimbra8.internal.convivian.com
239 [172.16.0.5])
240 by mailhub.convivian.com (Postfix) with ESMTP id 471DA66FB6;
241 Thu, 1 Feb 2018 20:34:08 -0500 (EST)
242 ARC-Seal: i=1; a=rsa-sha256; d=convivian.com; s=default; t=1517535248; cv=none;
243 b=HkK4AhtPFBUHtRUKKzTON3wyMj7ZLq881P2qhWg+lO8Y50V9SEc8lJ4dBIM3cj3ftfAbooPSLHAVejA89bpS1eAvODci6pOPaQWkBZmpdu+yPIxqX3FyOaCdIaZFbXaMQ1Jg5Sraf5mkCESmfjR5bCguAaZsnPQDF6wSN8VhbQk=
244 ARC-Message-Signature: i=1; a=rsa-sha256; d=convivian.com; s=default;
245 t=1517535248; c=relaxed/simple;
246 bh=9Cp8KoxNPc7FEuC29xB5bNWWadzdEFhXrX/8i+vd3g4=;
247 h=DKIM-Signature:Date:From:To:Cc:Message-ID:In-Reply-To:References:
248 Subject:MIME-Version:Content-Type:X-Originating-IP:X-Mailer:
249 Thread-Topic:Thread-Index:From;
250 b=jG+KnBrP2oq1z1upStMoWbM1fkS5zbUiir221Gy6h7ao5oy7Qc3m0pXgrSdhgGD4oX/kk2seEt2WAlPNwEsZyvYeG/80ctd/2+hwaVQ6JSOU83Rdd8im8HwMvXzXZIz8ATjPpOv21+xMrqlPSkD/l6X4VP+AAoVVkhW7f4GWcws=
251 ARC-Authentication-Results: i=1; mailhub.convivian.com; none
252 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=convivian.com;
253 s=default; t=1517535248;
254 bh=9Cp8KoxNPc7FEuC29xB5bNWWadzdEFhXrX/8i+vd3g4=;
255 h=Date:From:To:Cc:In-Reply-To:References:Subject:From;
256 b=LHXEAl5elmfkdXNdK24QonXpkiG38neuJoS7fSQXwZVZkR+cdYNr6eBxx3DF4reJO
257 NgzV5GFyPX6+LdIqR6rnC8BXhjvJq+pxLW3/wKx39W3ANYWRFm1dgyWBz99NxNNvk/
258 ruQkYYBBk9GPM52EyHNMvHciRAyaSk+VluGj6c6M=
259 Date: Thu, 1 Feb 2018 20:34:08 -0500 (EST)
260 To: Brandon Long <blong@google.com>
261 Message-ID: <1426665656.110316.1517535248039.JavaMail.zimbra@convivian.com>
262 In-Reply-To: <CABa8R6s3e1k=c9wQBtNBWvPT4BrXv3-2NnynyAfRseZ-5s6NKg@mail.gmail.com>
263 References: <CO2PR0501MB981081FA2C73CB83FA1C903F1FA0@CO2PR0501MB981.namprd05.prod.outlook.com>
264 <CAAQnKjAV3zEfP-J6JgTrv1jU9UPmf9dG9SPr-+q4jZ6PaGQjxg@mail.gmail.com>
265 <CAAQnKjBBLS9Lm2vnT3i+WUNhrvv2oDEMFEcyozw+YzyKS4G1qQ@mail.gmail.com>
266 <29030059.107105.1517497494557.JavaMail.zimbra@convivian.com>
267 <4f60039a-a754-ae4c-1543-0a978d9e13be@rolandturner.com>
268 <1544831589.110194.1517532064123.JavaMail.zimbra@convivian.com>
269 <CABa8R6s3e1k=c9wQBtNBWvPT4BrXv3-2NnynyAfRseZ-5s6NKg@mail.gmail.com>
270 MIME-Version: 1.0
271 X-Originating-IP: [172.16.0.5]
272 X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF58 (Mac)/8.7.11_GA_1854)
273 Thread-Topic: Gmail support of ARC headers from third-parties
274 Thread-Index: JantLkX01vLd7pyKcopbBWCs3yDbLQ==
275 Cc: arc-discuss <arc-discuss@dmarc.org>
276 Subject: Re: [arc-discuss] Gmail support of ARC headers from third-parties
277 X-BeenThere: arc-discuss@dmarc.org
278 X-Mailman-Version: 2.1.18
279 Precedence: list
280 List-Id: Discussion of the ARC protocol <arc-discuss.dmarc.org>
281 List-Unsubscribe: <http://lists.dmarc.org/mailman/options/arc-discuss>,
282 <mailto:arc-discuss-request@dmarc.org?subject=unsubscribe>
283 List-Archive: <http://lists.dmarc.org/pipermail/arc-discuss/>
284 List-Post: <mailto:arc-discuss@dmarc.org>
285 List-Help: <mailto:arc-discuss-request@dmarc.org?subject=help>
286 List-Subscribe: <http://lists.dmarc.org/mailman/listinfo/arc-discuss>,
287 <mailto:arc-discuss-request@dmarc.org?subject=subscribe>
288 From: Jered Floyd via arc-discuss <arc-discuss@dmarc.org>
289 Reply-To: Jered Floyd <jered@convivian.com>
290 Content-Type: multipart/mixed; boundary="===============2728806607597782871=="
291 Errors-To: arc-discuss-bounces@dmarc.org
292 Sender: "arc-discuss" <arc-discuss-bounces@dmarc.org>
293
294 --===============2728806607597782871==
295 Content-Type: multipart/alternative;
296 boundary="=_bda8d35f-e3be-4e59-9fc8-f78ed0af3226"
297
298 --=_bda8d35f-e3be-4e59-9fc8-f78ed0af3226
299 Content-Type: text/plain; charset=utf-8
300 Content-Transfer-Encoding: 7bit
301
302 >> Couldn't the first untrusted ARC signer (working in reverse chronological order)
303 >> simply have faked all the earlier headers and applied a "valid" ARC
304 >> signature/seal? This is why I figured you must trust the entire chain if you
305 >> want to trust the sender data.
306
307 > They can't fake an earlier signature unless they have the private key for the
308 > signing domain.
309
310 > Ie, a non-modifying hop is basically a no-op, unless you want to trust their
311 > auth results.
312
313 OK, sure; I agree with that. But I guess I see ARC as primarily for indirect mail flows that break DKIM (i.e. Mailman), in which case I think trust is needed to bridge those hops?
314
315 --Jered
316
317 --=_bda8d35f-e3be-4e59-9fc8-f78ed0af3226
318 Content-Type: text/html; charset=utf-8
319 Content-Transfer-Encoding: 7bit
320
321 <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
322 Couldn't the first untrusted ARC signer (working in reverse chronological order) simply have faked all the earlier headers and applied a "valid" ARC signature/seal?&nbsp; This is why I figured you must trust the entire chain if you want to trust the sender data.<br></blockquote><br><div>They can't fake an earlier signature unless they have the private key for the signing domain.</div><br><div>Ie, a non-modifying hop is basically a no-op, unless you want to trust their auth results.</div></div></div></blockquote><div>OK, sure; I agree with that.&nbsp; But I guess I see ARC as primarily for indirect mail flows that break DKIM (i.e. Mailman), in which case I think trust is needed to bridge those hops?<br></div><div><br data-mce-bogus="1"></div><div>--Jered<br data-mce-bogus="1"></div></div></div></body></html>
323 --=_bda8d35f-e3be-4e59-9fc8-f78ed0af3226--
324
325 --===============2728806607597782871==
326 Content-Type: text/plain; charset="us-ascii"
327 MIME-Version: 1.0
328 Content-Transfer-Encoding: 7bit
329 Content-Disposition: inline
330
331 _______________________________________________
332 arc-discuss mailing list
333 arc-discuss@dmarc.org
334 http://lists.dmarc.org/mailman/listinfo/arc-discuss
335
336 --===============2728806607597782871==--
337 .
338 ??? 250
339 QUIT
340 ??? 221
341 ****
342 #
343 exim -DSERVER=server -DNOTDAEMON -q
344 ****
345 exim -DSERVER=server -DNOTDAEMON -q
346 ****
347 #
348 #
349 #
350 #
351 #
352 #
353 #
354 #
355 #
356 killdaemon
357 #
358 no_stdout_check
359 no_msglog_check