[Mimedefang] Reputation Reporting Protocol submitted to IETF as an I-D

[David F. Skoll]

- wrote:

> I can say this right off: Encoding the timestamp as an integer with
> an anchor year is going to be a problem (e.g in 2038 or 2106)
> requiring a future version upgrade.

No, it's not.

We are not encoding the timestamp.  If you read the RFC carefully, you'll
see that we're encoding the low-order 32 bits of the timestamp.  The *only*
purpose of that field is to help detect and fend off replay attacks.

If an attacker wants to hold onto a packet for 2^32 seconds (~136
years) and then reinject it... well yeah, we don't protect against
that.

> Maybe you don't care about the 27-year timebomb you're giving yourself.

Absolutely we don't care; see above.

> IP-address-types: Consider adding as a separate value "spamtrap"
> that occurs as a result of delivery to a spamtrap address.

IMO, that's the same as AUTO-SPAM, but I suppose we could add another TYPE
code.

> Section 8 - Example Report: Should use an IPv6 address from the
> documentation prefix (2001:DB8::/32) instead of a live address.

OK; I'll fix that in the next version.

-- David.