On 03/Feb/10 17:45, Chris Lewis wrote:
Alessandro Vesely wrote:
The receiving end does not /have/ to zap prior instances of the same
[Authentication-Results] field.
No, it doesn't technically have to, but it _will_ have to give the
client a hand in making sure the client doesn't trust bogus/malicious
ones or ones outside of the receiving site's policies.
An ADMD may keep a database of known bogus authserv-id's (OpenDKIM
apparently supports this). It may prevent gullible users from trusting
questionable servers. However, it shouldn't be needed unless MUAs
repeatedly ask users to trust any authserv-id just because they found
it in some messages' headers.
Removing the ones it doesn't want the client to respect and/or rewriting
the ones it does want the client to respect, or simply replacing them
all with its own is the best way of doing that.
Like removal of "Received" traces, this shouldn't be done frivolously.
It filters off any maliciously forged Authentication-Results bearing
its own authserv-id, but they wouldn't have provided a different
target anyway.
Why not? Why wouldn't a scammer attempt to divert the recipient's TiS
buttons to /dev/null, DDOS someone else, or divert complaints away from
their provider who might zap them?
That's not possible: the authserv-id is just a naked token. Actually,
it doesn't even have to be an existing mail domain. Overloading RFC
5451 in order to derive a destination for ARs is just a convenience
for MUAs. Otherwise, users could just spell out a list of ARF
recipients. The problem with that approach is how to avoid that MUAs
have to resort to heuristics when a user has multiple accounts or
forwarders. Since the Authentication-Results header conveys exactly
the same meaning --the party responsible for receiving a message-- the
overload is correct, IMHO.
However, Authentication-Results contains no further meta-info,
command, or indication that would be used for sending ARs. Just the
authserv-id token itself.
In general, a (trusted) report from a client should reach the
originating domain, whose operators can make the best use of it,
assuming they're honest.
And assuming that meets the recipient server's policies. As a corporate,
for example, we must have the final word on what reporting our users do
and to where. That will often _not_ be where the sender or forwarder is
trying to tell the client.
For simplicity, you may well want to have the core specification require
that the receiving MTA makes all the choices at transit time, and
removes all forwarding instructions that it doesn't agree with.
Hmm... I like the idea that an MTA may acknowledge ARF reports in
transit, as it allows users to communicate to their ISPs that they
have enabled some other authserv-id. However, there may be better ways
to achieve the same effect without specifying SMTP behavior that would
be unique to ARF handling.
Slight alterations of messages that give corporate acknowledgments are
quite usual, e.g. footers and DKIM signatures. However, changing a
message's destination is not common, AFAIK.
That means that the client, assuming that the client knows that the
receiver is doing all the work, doesn't have to do any cryptographic
verification, and the receiver may not need to either.
The client can rely on the fact that all messages in a given mailbox
have been received by the relevant server. However, a server doesn't
know that an ARF contains a message that it had previously delivered
to the reporter. This is different from webmail.
The indirection may well be desirable, but you have to ensure that it is
convenient to do so (in other words, make sure that the client's
provider's AR handling _know_ what routing decisions they're being asked
to assess and implement).
Well stated. Policies and experience are essential here, but it would
be desirable to have a set of easy rules that a newcomer may/ should
follow in order to behave correctly. Perhaps, presentation of new mail
domains and reputation tracking will eventually be specified.
As for tying an MTA to abuse reports handling, I think it is the most
convenient choice. The kind of spam that we may be able to control by
properly routing ARs does not require the immediateness of HTTP.
The MTA is only essential to abuse report handling insofar as the abuse
reports may adjust the filters.
Not only that. User IDs and authentication methods may be specific for
mail apps. We should follow ease of development and deployment.
It'll be convenient to do the AR
handling on the MTA in some instances, but in many it will be not a good
choice. A specification design that makes AR handling independent of
the MTA is a better one. You can run it co-resident if you wish. But you
don't have to. Making the spec require too much of the MTA function
would be a mistake in that regard.
Some task may deserve a different tool, of course. However, making the
spec too general, e.g. reporting spam using different transports, may
become cumbersome.
Do you have a specific case in mind?
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg