The "dumpsterfire" mailing list is for the discussion of security and
privacy issues related to the IoT (Internet of Things). Arguably,
the entire IoT *is* a security and privacy issue, but we'll get to that
in good time.
If you want to join, you can either use the list's web page:
http://www.firemountain.net/mailman/listinfo/dumpsterfire
or the list's subscription/unsubscription address:
dumpsterfire-request@firemountain.net
The list is public and so is its archive.
---rsk
Unfortunately I don’t see this as having very much connectivity where I am at.
host firemountain.net
firemountain.net has address 207.114.3.55
firemountain.net mail is handled by 10 taos.firemountain.net.
firemountain.net mail is handled by 20 ukiah.firemountain.net.
host www.firemountain.net
www.firemountain.net has address 207.114.3.55
Sending 5, 100-byte ICMP Echos to 207.114.3.55, timeout is 2 seconds:
!....
Success rate is 20 percent (1/5), round-trip min/avg/max = 51/51/51 ms
Tracing the route to firemountain.net (207.114.3.55)
1 <redacted> 0 msec 0 msec 0 msec
2 142.254.152.249 9 msec 9 msec 17 msec
3 ae62.nwblwi1801h.midwest.rr.com (24.164.241.145) 16 msec 16 msec 9 msec
4 be63.milzwift01r.midwest.rr.com (65.31.112.122) 25 msec 16 msec 17 msec
5 be40.clmkohpe01r.midwest.rr.com (65.25.137.109) 25 msec 25 msec 34 msec
6 be1.clmkohpe02r.midwest.rr.com (65.29.1.35) 34 msec 34 msec 25 msec
7 ae1.uparohgd01h.midwest.rr.com (24.33.161.209) 34 msec 42 msec 25 msec
8 69.23.10.160 34 msec 25 msec 25 msec
9 rrcs-98-102-146-106.central.biz.rr.com (98.102.146.106) 25 msec 34 msec 25 msec
10 xe-0-0-0.upa-core1.expedient.com (66.230.78.130) 33 msec 34 msec 25 msec
11 et-0-2-0.acm-core2.expedient.com (209.166.144.209) 34 msec 34 msec 34 msec
12 irb-4038.acm-core1.expedient.com (209.166.144.21) 33 msec 33 msec 25 msec
13 et-3-0-0.152-core2.expedient.com (66.230.78.194) 33 msec 33 msec 34 msec
14 ae2.152-core1.expedient.com (66.230.78.161) 42 msec 34 msec 34 msec
15 xe-0-3-0.fil-node.expedient.com (206.210.75.234) 42 msec 42 msec 51 msec
16 xe-0-3-0.1sc-node.expedient.com (216.230.108.246) 50 msec 42 msec 59 msec
17 ten1-6-2.tdp-core.expedient.com (216.230.108.229) 42 msec 42 msec 50 msec
18 firemountain.net (207.114.3.55) 50 msec 42 msec 51 msec
HTH
* no HTTPS
* archive is returning HTTP 403
A dumpster fire, indeed.
No HTTPS?!?! Where are the tar and feathers??!?!!
This isn’t something that needs HTTPS.
True, but our browser overlords would condemn it because they seem
to believe that EVERYTHING should be guarded by https.
- Brian
* no HTTPS
HTTPS isn't needed for this application. I'll probably add it anyway
when I have a chance, but there are other things ahead of it.
* archive is returning HTTP 403
That is exactly what you should expect to see when a Mailman archive is empty,
as it is for any new mailing list. Now it's not. So now you won't.
---rsk
It's not the best-connected or most powerful server, however it's been
running a bunch of public/private mailing lists for many years and
for that purpose, it's sufficed nicely. (That's one of the many major
advantages of mailing lists over web forums: they don't need much in
the way of connectivity, bandwidth, or horsepower.) Sure, I'd like
to have bigger/better/faster/more, but since I'm paying for this
out of my own pocket...
---rsk
I respectfully disagree:
http://www.firemountain.net/mailman/options/dumpsterfire/bofh@example.com
asks for a "password" which is then transported over clear text. The year
is 2019 and there's always letsencrypt SSL certs. Admittedly, mailman does
send you the password in clear text over SMTP if you ask for it.
-andreas
To borrow a quote: The 'S' in IoT stands for 'Security'.
but if done right, fwiw, wouldn't that be sent over SMTP using TLS encryption? (but, then again, that ALSO requires a certificate!)
11 Jan. 2019 г., 22:33 Rob McEwen <rob@invaluement.com>:
but if done right, fwiw, wouldn’t that
be sent over SMTP using TLS encryption
So STARTTLS strip is not a problem anymore?
but if done right, fwiw, wouldn't that be sent over SMTP using TLS encryption?
Oy vey. in-flight vs at-rest encryption. <facepalm>
(but, then again, that ALSO requires a certificate!)
Let's Encrypt works perfectly fine for that too. }
I thought it stood for ZEPPELIN.
Additionally, subscribe mail to the email address is bouncing.
Anne
Anne P. Mitchell,
Attorney at Law
CEO/President,
SuretyMail Email Reputation Certification
http://www.SuretyMail.com/
Certified Sender DNSBL here: iadb.isipp.com
Info here: https://www.isipp.com/email-accreditation/for-isps/
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting
> but if done right, fwiw, wouldn't that
> be sent over SMTP using TLS encryptionSo STARTTLS strip is not a problem anymore?
If you deploy DANE (client and server sides) then stripping STARTTLS is
ineffective for the target domain.
We (isc.org) have but gmail.com hasn’t (server side at least). On could be
asking why you are using gmail.com when they don’t care enough to signal to
the world that STARTTLS is supported and should be there in the EHLO.
% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.
; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4910
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: bfabca20a2ed6fe032fae4e75c38f7eecca21769def0a3e3 (good)
;; QUESTION SECTION:
;isc.org. IN MX
;; ANSWER SECTION:
isc.org. 7140 IN MX 20 mx.ams1.isc.org.
isc.org. 7140 IN MX 10 mx.pao1.isc.org.
isc.org. 7140 IN RRSIG MX 5 2 7200 20190206233314 20190107233314 19923 isc.org. UBu26XwokUyCwZvBzp5+kajy686RF4cdA/Un3Z3vtEARG8qx0hQfHoTk lGfGPkt21QdZmqX+ZJcdO3LfA+qU9A3aEJMXZi9aMZkPDWu1aPsJBu6U 3U3Tj9j+DsqL2Uk780TAqQQQWFUwIHF+y0hcRIWPaqUuvygl/5jxdVDN Mls=
;; ADDITIONAL SECTION:
mx.pao1.isc.org. 3541 IN A 149.20.64.53
mx.ams1.isc.org. 3544 IN A 199.6.1.65
mx.pao1.isc.org. 3541 IN AAAA 2001:4f8:0:2::2b
mx.ams1.isc.org. 3544 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 3541 IN RRSIG A 5 4 3600 20190206233333 20190107233333 13902 pao1.isc.org. WrDcCGC0SmNUSh+DBxogVXWU2PQVpJ/6S/WJxpU4fLDpI+0J85aep+e1 NwZRUuw9N5RRuslQSz0y+aiwB0RACq2wbPUxDem21KpzKE8rlrAlf0U9 k9sT1PeCkWu7QOiWgEksnoJijyCVY41Q/GB0HnWzaO4jUtay6e/PBj4c IiA=
mx.pao1.isc.org. 3541 IN RRSIG AAAA 5 4 3600 20190206233333 20190107233333 13902 pao1.isc.org. EaYgxAGrmJ9oiX4u2DfIcHKCqen3RNGylmWT0VjJ8VWY5e/c5TA1eI5U evGsvYhvLD4WvR8hzvKxp4Pc5EYKLoB+YRI4ttUgnTydsEI0xFCcgB4+ dFb+89h8e6tHSPhUa1wa7ObriKm1O5FzplEXLfNFbgEUN6oJOIMw7q8w cC8=
_25._tcp.mx.pao1.isc.org. 3543 IN RRSIG TLSA 5 6 3600 20190206233333 20190107233333 13902 pao1.isc.org. liSDcLgGpDXqgTxkv2sQBI3OsACPflpxoZxcrgSge4yTe5gA97NOPe0l ECmDBPzUkhcRI6Mwv+uBCmm5FBvgh0leNxLXzACdkCX8EscE3v74wd5o ReCRGFAhV6TBjycwejkGARVTYF23RyRflq2/fRV2hoOdH2ImcW7/SMqA 8Jg=
mx.ams1.isc.org. 3544 IN RRSIG A 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. E+6nzEbFAcftlr3UTaCcw0LAHYIdVe5TNfyIwVwU71AzZB22jiif/BrQ KxemOrR7LT7ukfDRjnEzfV1/s0Wwfxh0b79otxrDwssKzNKz9XhaIhVf j17oyuQBkYjYv5RBuwsrmKQmSbu56Zu7G35xp2qbKi6E+3lpXPghnrnJ DBk=
mx.ams1.isc.org. 3544 IN RRSIG AAAA 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. ov/6HUTx8v7t31KBYVgDy02Bpe8rJX431vPDdRZvKKhffFrYmUOIXEqD Q/3+DNV1axSJCTONJ1NwzoSC8LDwQQFUcAsXnhcW/C/Z3rbaEthetmmP TERuRGjF3QdA+qFM8RCc83s+hp1RXo5cU+9wA8OTPT5nTmfthkDs/cUi 0o8=
_25._tcp.mx.ams1.isc.org. 3545 IN RRSIG TLSA 5 6 3600 20190206233315 20190107233315 5730 ams1.isc.org. qdzOyIbkPhufqw6/B5bwpxJ0pfVeUay2v8O5spUa+xgHdLQFNS851vlW KOYrNfZALDomXkOyfAVTEZXQ1g3xf0gzIcRCy0PHcgDtgl5a56AilFGB n6LZVkh6lbAkQ8lSmlKWmOvAmJnXh6L6dX8/CQzpWT7G0EEL1EcvLW6p uZ0=
_25._tcp.mx.pao1.isc.org. 3543 IN TLSA 3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0
_25._tcp.mx.ams1.isc.org. 3545 IN TLSA 3 0 1 5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916
;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 12 07:09:18 AEDT 2019
;; MSG SIZE rcvd: 1555
%
11 Jan. 2019 г., 23:19 Mark Andrews <marka@isc.org>:
So STARTTLS strip is not a problem anymore?
If you deploy DANE (client and server
sides) then stripping STARTTLS is
ineffective for the target domain.
If you defer to send (and finally bounce) everything targeted at a domain that fails TLSA lookup, then fair enough. I don’t think this is (and is going to be in the near future) the case for the dumpsterfire mailing list, but you may rightfully assume I haven’t checked yet.
gmail.com hasn’t (server side at least).
Google folks are on this mailing list, so it’s best if they speak for me (though I believe I pretry much know their reasoning).
Whaddya expect guys, the mailing list is hosted on an embedded DVR recorder
but if done right, fwiw, wouldn't that be sent over SMTP using TLS encryption?
Oy vey. in-flight vs at-rest encryption. <facepalm>
which is why i said "fwiw", acknowledging upfront that TLS transmission encryption has a limited scope. I guess you missed that? But I was specifically replying to a complaint about passwords being sent in plain text, and I was suggesting that TLS would solve that problem. At that point in the discussion, it wasn't a discussion about all things encryption. ("context" is very helpful - are you still facepalming?)