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
++++++++++++++++++++++++++++++++++++++++