On 07/02/2014 06:27 PM, Andrew Daviel wrote:

Now if I want to get DMARC functionality I'll have to jump past the RedHat/CentOS release and build 2.1.18, and re-patch for CSS.

See the FAQ at http://wiki.list.org/x/jYA9. It is fairly straightforward to make list, domain or site specific HTML templates that will survive upgrades.

This is probably a case of beating a dead horse after everyone switched to automobiles, but nevertheless:

We had an occasion where some private information got forwarded to a public mailing list and then got found by a search engine. Probably happens all the time. At least one of these messages had some boilerplate on the bottom saying "may be confidential, do not forward" etc.

Computers are better than people at reading boilerplate. It would be nice if there was some way to flag a message "do not archive", or even "do not forward" so that a user would have to do something to override that. I found "X-No-Archive" in wikipedia that was apparently honored by google when archiving usenet.

In an ideal world hundreds of people would immediately agree that this was an excellent idea, get an RFC written, and everyone would implement it by next year. Not going to happen, I know.

I wondered if this had been done already somehow, or considered and shot down, and how others handle the problem.

Andrew Daviel writes:

At least one of these messages had some boilerplate on the bottom saying "may be confidential, do not forward" etc.

Computers are better than people at reading boilerplate.

Unfortunately, the footer boilerplate is non-standard.

In an ideal world hundreds of people would immediately agree that this was an excellent idea, get an RFC written, and everyone would implement it by next year. Not going to happen, I know.

Only because it already has, except for the RFC, and

http://people.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html

mentions the definition of "X-No-Archive: Yes".

In practice, I believe most of the standard (Mailman's Pipermail[1], mail-archive.com, GMane) and large-scale proprietary archiving engines (Google and Yahoo! Groups) already do.

I wondered if this had been done already somehow, or considered and shot down, and how others handle the problem.

I'm not sure why Palme's I-D wasn't taken to RFC (Informational) status; probably it just was considered insufficiently authoritative since new headers are being invented all the time, eg, X-Spam and relatives aren't in it).

However, the real practical problem is that to be reliable, it needs to be a header field, and insertion of header fields is the province of mail clients, over which the IETF has no authority. (That is, the IETF can define a header field's semantics, but it is up to the user or the mail client to add it, and the IETF can't mandate addition of a user choice field the way it can mandate addition of From, Date, and Message-ID.) Although archivers recognize X-No-Archive, few users realize that there is a header in mail to which they can (in principle) add arbitrary fields, and even fewer know how to add the field with their mail-client-of-choice.

I think the best strategy is for mail clients and outgoing mail gateways that add confidentiality notices to also automatically add "X-No-Archive: Yes" to the header. And that's what I suggest you recommend to your posters. Not all of them will have the skills and access to do so, of course, but it will save the competent ones the occasional headache.

Footnotes: [1] I need to check Mailman 3's HyperKitty.

http://www.mail-archive.com/faq.html specifies "X-No-Archive: yes"

It's been a long time, but I vaguely remember lowercase 'yes' being canonical which is why we specify it that way in the FAQ. In practice mail-archive.com treats the header as case insensitive.

Here's some data on common practices, taken from a recent week of mail-archive.com's inbound mail.

$ zgrep -i "^x-no-archive:" *.mbox.gz | cut -f3 -d":" | sort | uniq -c

 72  no
183  No

6407 yes 108 Yes 47 YES

On 02/12/2015 12:28 AM, Stephen J. Turnbull wrote:

Andrew Daviel writes:

...

Experimentally, if I add "X-No-Archive: no" in Alpine or Thunderbird, pipermail will not archive the message,

Do you consider that a bug?

I'm not sure why anybody would use "X-No-Archive: no" in reality, I wonder if it's a mistake in interpreting the double negation.

As I posted earlier Mailman does not archive a message with an X-No-Archive: header. It doesn't look at the content which could be yes, no, empty or anything else. This is deliberate.

It does look at the content of an X-Archive: header which must be (case insensitive) no to suppress archiving.

This is explained in the code and comments which Andrew quoted in the same post partially quoted above

I found it implemented in /usr/lib/mailman/Mailman/Handlers/ToArchive.py, viz. # Common practice seems to favor "X-No-Archive: yes". No other value for # this header seems to make sense, so we'll just test for it's presence. # I'm keeping "X-Archive: no" for backwards compatibility. if msg.has_key('x-no-archive') or msg.get('x-archive', '').lower() == 'no': return

So the experiment just confirms that the code does what it says. Given that

X-No-Archive: no

apparently does occur in the wild, if we can confirm that the semantics of this should be 'do archive', file a bug and I'll fix it.

On Feb 12, 2015, at 01:42 AM, Mark Sapiro wrote:

apparently does occur in the wild, if we can confirm that the semantics of this should be 'do archive', file a bug and I'll fix it.

It's been ages, but IIRC the reason for accepting any value is exactly because of the double negative. People had a difficult time parsing it out, and as you observe, it doesn't make much sense to deliberately say "X-No-Archive: no".

It's crappy (inherited, historical) ui but it's not a bug.

Cheers, -Barry

I checked and these two lists are responsible. One uses 'No' and the other uses 'no' for every message. I can't speak to the intention. There are an impressive number of headers on each message including DKIM but I don't see a clue as to the list server software.

http://www.mail-archive.com/iagi-net@iagi.or.id http://www.mail-archive.com/fgmi@iagi.or.id

On Feb 12, 2015, at 12:50 PM, J.B. Nicholson-Owens wrote:

I believe this is the case for two reasons:

1. Structurally: Few search engine companies will throw away an opportunity

to collect data when there's so much for that organization to gain by indexing that data.

2. Specific to Google: When Google took on DejaNews's archive of Usenet posts

Google's search engine Google released copies of posts labeled "X-No-Archive: yes" for a while.

Overall, I think people are better off understanding that their boilerplate is not binding on most people (if anyone) and they need to be more careful in what they send.

Aside from the fact that you should just assume that nothing on the intarwebs is secret. ;)

Cheers, -Barry

On Thu, 12 Feb 2015, Stephen J. Turnbull wrote:

Andrew Daviel writes:

...

http://en.wikipedia.org/wiki/X-No-Archive says "If the X-No-Archive field is set to "No", or the field is absent, a Usenet archive will not recognize a prohibition on archiving the message."

Experimentally, if I add "X-No-Archive: no" in Alpine or Thunderbird, pipermail will not archive the message,

Do you consider that a bug?

I'm not sure. When I look at the Mailman documentation, it's clear enough, so it's a feature. But it seems at variance with the other applications mentioned.

I was trying to add the header without reading the documentation - the other custom header already in my configuration file had a value, so I assumed that a value was required. Turned out it was not.

• I realized later that XNA doesn't actually solve my problem; mail

headers don't get promoted when forwarding mail. I need X-No-Forward...

Andrew