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.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
