-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Laird Breyer writes:
On Oct 20 2004, William Leibzon wrote:
I have commented on authentication of received headers before some time
ago on asrg and I think on ietf-smtp (??) or ietf-822, would have to
search archives to find those posts.
Thanks, I'll try to look them up. Do you know roughly when?
But basicly the only way to truly authenticate this data is to use
cryptography, anything else is herecy and easily defeated and forged.
You've obviously thought about this, so it should be fairly easy to provide
a concrete example. This would be very valuable for the filtering group.
Can you explain a successful forgery attack on the problem I posted?
To fix ideas, here is perhaps the simplest concrete problem:
A -> M3 -> B. Here A is a spammer which sends mail to B, by talking
directly to the SMTP server M3, whose domain name is
mail.bigbucks.com. B's email address is bee(_at_)bigbucks(_dot_)com, and you
can
assume that B reads mail directly from the mail spool.
Your task is to write down for me a simple RFC2822 email message which
contains a forged Processed: header as outlined in my proposal, and
which can be submitted by SMTP to M3, in such a way that when B
receives the mail, it is guaranteed that B thinks the Processed:
header was added by an internal filter on the machine M3.
You may assume that it is known to A that the filters on machine M3
are named SpamAssassin, Bogofilter and GreatGooglyMoogly, and you may
also assume that those filters are stupid enough to allow the message
through to B in this instance.
BTW, I've been very remiss in commenting, sorry guys! But just worth
noting at this point that we've implemented a header trust-path algorithm
in SpamAssassin to deal with the similar problem of what Received headers
can be trusted:
- - 1. user or admin can specify a set of CIDR masks in a config parameter
called "trusted_networks".
- - 2. SpamAssassin will not trust Received headers added by hosts that
aren't in those netmasks.
As you said previously, the Received header is always prepended. This can
be exploited more simply for the Processed header, as long as the
Processed header is *also* prepended *only*, and never appended, by each
processor.
That way we can use the Received-header trust path to figure out which
Processed headers are trustworthy; if the nearest Received line *after* a
Processed header was added by an untrusted host, we can't trust the
Processed header either. OTOH, if the Received header after the Processed
header is trusted, we can trust it.
That gets around the problem of identifying ID or datestamp strings from
arbitrary formats of Received headers, which is certainly a hard problem,
I can tell you. (we do it for some bizarre reason ;)
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFBdwqaMJF5cimLx9ARAt9bAJ9DxXmeCnaUGTsXW7sfEQwc7O/m0gCfVuwu
PF58c5424nhm29mYI0Qcy24=
=d72S
-----END PGP SIGNATURE-----