On Sun, November 9, 2014 00:06, Valeri Galtsev wrote:
On Sat, November 8, 2014 8:35 pm, Stephen Harris wrote:
On Sat, Nov 08, 2014 at 05:58:53PM -0800, Keith Keller wrote:
The fundamental reason is because Mailman is rewriting the headers in an incompatible way. It is not his site's usage of DKIM. This is a known issue with Mailman. (I used to have a good link explaining the issue, but can't find it now; if I find it later I'll post it.)
So we have a 20-year old piece of technology ("mailman") and a modern proposal ("DKIM")... and somehow it's mailman's fault. Uh huh.
Note; it's not just mailman that has problems, it's _any_ mail forwarder. Going back 27 years to my first Unix account, I could create a file called ".forward" that would forward my mail to another address. This is BROKEN by DKIM.
Any constructive suggestion how to deal with e-mail of people who moved on? Forwarding is a a solution. What is suggested instead (in the realm of DKIM)?
Valeri
If you want to read intelligent people throwing tantrums search at the IETF mailing list archives for DKIM, DMARC and SPF; and read; and weep.
The problem that DMARC, DKIM, and SPF seek to solve is intractable. So long as the cost of email is borne by the recipients and there are no sensible restrictions of the volume of traffic a single source can generate then unwanted email is going to be created and transmitted. All of this jiggery-pokery respecting message signing and sender policy frameworks just shows how intractable it is.
DMARC is. . ., well I do not know what benefit one obtains by discovering that some IP address on mainland China is again purporting to belong to our domain and sending out email. What news! Next someone will tell me that not everything on the Internet is factual!!
In our case we believe a more pressing problem has to do with authenticated connections between mail servers and the whole sorry mess that is CA driven PKI. The certs and signatures for PKI have to be moved into DNS RRs so that the current system of privately owned CAs just goes away. It is totally flawed as it assumes, and requires, a strict hierarchy for identification. That vision simply does not describe the Internet. Anything that will work for identification on the Internet ultimately will have to resemble DNS.
For SMTP the mail server that connects should always use STARTTLS and have its IP address reverse checked against its A RR to locate an associated RR something like SSHFP. That then is used to verify its identity and the validity of its certificate. No match no traffic. That will not solve SPAM and UCEM but that is not the point. It will guarantee that our traffic is moving along verifiable routes and that, for us, is very important.
That also, as a side effect, would hide email headers (meta data) on all point to point connections. Our observations with respect to our own servers are that for correspondents running their own mail servers all, or virtually all, of those connections presently are point to point.
As for the poor sots that have handed over their email service management to Google and the the like. Well those people have nothing to hide. Which is a good thing for them. Because everything they transmit is open to inspection by third parties, trusted or not. And kept forever, whether they wish it or not.
On Mon, November 10, 2014 9:53 am, James B. Byrne wrote:
On Sun, November 9, 2014 00:06, Valeri Galtsev wrote:
On Sat, November 8, 2014 8:35 pm, Stephen Harris wrote:
On Sat, Nov 08, 2014 at 05:58:53PM -0800, Keith Keller wrote:
The fundamental reason is because Mailman is rewriting the headers in an incompatible way. It is not his site's usage of DKIM. This is a known issue with Mailman. (I used to have a good link explaining the issue, but can't find it now; if I find it later I'll post it.)
So we have a 20-year old piece of technology ("mailman") and a modern proposal ("DKIM")... and somehow it's mailman's fault. Uh huh.
Note; it's not just mailman that has problems, it's _any_ mail forwarder. Going back 27 years to my first Unix account, I could create a file called ".forward" that would forward my mail to another address. This is BROKEN by DKIM.
Any constructive suggestion how to deal with e-mail of people who moved on? Forwarding is a a solution. What is suggested instead (in the realm of DKIM)?
Valeri
If you want to read intelligent people throwing tantrums search at the IETF mailing list archives for DKIM, DMARC and SPF; and read; and weep.
The problem that DMARC, DKIM, and SPF seek to solve is intractable. So long as the cost of email is borne by the recipients and there are no sensible restrictions of the volume of traffic a single source can generate then unwanted email is going to be created and transmitted. All of this jiggery-pokery respecting message signing and sender policy frameworks just shows how intractable it is.
DMARC is. . ., well I do not know what benefit one obtains by discovering that some IP address on mainland China is again purporting to belong to our domain and sending out email. What news! Next someone will tell me that not everything on the Internet is factual!!
In our case we believe a more pressing problem has to do with authenticated connections between mail servers and the whole sorry mess that is CA driven PKI. The certs and signatures for PKI have to be moved into DNS RRs so that the current system of privately owned CAs just goes away. It is totally flawed as it assumes, and requires, a strict hierarchy for identification. That vision simply does not describe the Internet. Anything that will work for identification on the Internet ultimately will have to resemble DNS.
For SMTP the mail server that connects should always use STARTTLS and have its IP address reverse checked against its A RR to locate an associated RR something like SSHFP. That then is used to verify its identity and the validity of its certificate. No match no traffic. That will not solve SPAM and UCEM but that is not the point. It will guarantee that our traffic is moving along verifiable routes and that, for us, is very important.
That also, as a side effect, would hide email headers (meta data) on all point to point connections. Our observations with respect to our own servers are that for correspondents running their own mail servers all, or virtually all, of those connections presently are point to point.
As for the poor sots that have handed over their email service management to Google and the the like. Well those people have nothing to hide. Which is a good thing for them. Because everything they transmit is open to inspection by third parties, trusted or not. And kept forever, whether they wish it or not.
James, thanks a lot for nice write-up!
As far as google and the likes are concerned... even though I'm not using any of them, my messages are too filed there through the ones who use them (even when it is not straightforward, e.g. when they forward to their ... account). Sigh.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, Nov 10, 2014 at 9:53 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
As for the poor sots that have handed over their email service management to Google and the the like. Well those people have nothing to hide. Which is a good thing for them. Because everything they transmit is open to inspection by third parties, trusted or not. And kept forever, whether they wish it or not.
Well, yeah... If I wanted to keep secrets, I wouldn't be sending them over the internet at all. You don't really trust your software or other third parties that much, do you?
-
James B. Byrne -
Les Mikesell -
Valeri Galtsev