Quoting Eric Dean <eric(_at_)purespeed(_dot_)com>:
"Mailing lists may include CRI-Sender-Exempt headers to
indicate that challenge messages should not be posted to
the mailing list..."
What will be the content of such a header?
Good question...it could be blank..like an HTTP no-cache header..or
maybe have some content.
It should probably identify the mailing list i.e.
CRI-Sender-Exempt: asrg(_at_)ietf(_dot_)org
That way the recipient could whitelist the header for now and always.
This seems like a reasonable suggestion.
I'm not sure what would be reasonable software behaviour when
such a header is seen in an incoming message. To whitelist
automatically based on the presence of such a header would open
the system to abuse by spammers. I suppose well-behaved software
would ask the user whether they want to whitelist the address
and let the user decide.
I know we're only specifying interoperability rather software
behaviour, but it's useful to think about how software would
interpret such headers.
If so, what would stop a
spammer from adding such headers to their messages?
Nothing. However, a well-implemented CR system should simply suppress
a challenge message to the sender...but should probably not forward the
message as a trusted source unless the recipient whitelists.
The issue of trust between one stage of delivery and the next is
one which does concern me with CR systems.
In general, when a CR-compliant MTA receives an incoming message
which claims to have been challenged and accepted... how can the MTA
at this stage ensure that such headers were not forged?
I suppose it comes down to which systems have access to the consent
tokens for that specific sender/receiver pair: only the systems which
have access to those tokens can verify if they are valid. This could
be done using a cache scheme such as that raised recently by Danny
Angus:
http://article.gmane.org/gmane.ietf.asrg/5760
As I'm sure everyone recalls, that idea was in the context of
cacheing consent policy rules to allow messages to be dropped
earlier in the delivery chain (close to the sender) with the
intention of reducing the spread of network traffic due to spam.
In the worst case, even if no such cache scheme were implemented,
I'm sure the end-reciever's MUA would know all of the relevant
consent tokens and could therefore accept or block messages at
the last stage of the delivery chain. If this is true then
delivery of "bad" messages (with possibly invalid CRI headers)
earlier on could still be detected at the final step before such
messages appear in the recipient's in-box.
I'm not trying to dictate how a CR system should be designed..but am
trying to provide a basic set of interoperability procotol messages
to automate interaction
Ok, thanks for pointing that out.
The need to rewrite mailing list software to generate such headers
is potentially more of an issue. Supposing I decided to use CRI
yet subscribed to some mailing lists which didn't generate such
headers.
Yes, however, many CR systems today identify lists. Also, mailing
lists would eventually add the header..it's not necessary day 1.
I'll admit this is one of the reasons the CRI proposal does seem
promising because it doesn't require the whole internet to change
overnight. Of course, like most proposals, it would benefit much
more if it were widely implemented.
[Supposing I decided to use CRI
yet subscribed to some mailing lists which didn't generate such
headers.] How could I ensure such messages got through?
I don't believe you can.
Therein lies a major problem for CRI and indeed CR systems in general.
To find a way around the issue, it might be worth thinking about
the possible format of mailing list messages.
Generally speaking, most mailing lists have these delivery options:
- digest
- single-message
- no delivery (web archive - irrelevant here)
The characteristics of a digest message are that:
- it usually arrives "from" the same e-mail address
e.g. listname(_at_)somewhere(_dot_)org,
listname-announce(_at_)somewhere(_dot_)org etc.
- its reply-to address is usually the same as the "from" address
- it may contain multiple actual messages, although these will
probably not be separated in a format which allows automatic
parsing (so this property is of little use in practice)
The characteristics of a single list message are:
- its "from" address is that of the sender, which could be anyone
authorised to post messages to the mailing list
- its "reply-to" address may or may not be set to that of the list
address (I think this depends on the configuration of the list
software)
By convention, the subject line of such messages often (not always)
contains the name of the list from which the message originated,
as with [ASRG] here.
There are some standards proposed which are relevant. Aside from
the usual RFC 2822, RFC 2919 proposes a "List-Id:" header which
can be used to recognise mailing list messages. RFC 2369 also
defines additional headers for mailing lists which might be of
some help in recognising mailing list messages.
Of course, as with any headers, these could be forged by a spammer.
The question is whether it would be sufficiently difficult to forge
such headers? This is why the use of a unique consent token in a
header is difficult to forge, because it's hard to guess for anyone
who doesn't know it in advance.
If messages from mailing lists can be reliably recognised by a
machine then they can be dealt with in a way which is "as automated
as possible". I'm thinking about how to reduce the pain for the
users of CRI during the time when mailing list software has yet to
be rewritten.
Andrew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg