- 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. _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
