There was some discussion about the length of SRS-encoded return addresses,
even suggesting using base64 rather than base36 to minimise them,
introducing possible problems with case-sensitivity.
What doesn't seem to have been suggested so far is that it's not even
necessary to include the timestamp in the SRS address at all.
(1) In the simplest case: you rotate your signing secret every day (e.g. by
appending utime/86400 to it). Then if you want to check that a message is
valid up to 7 days old, you just check the hash against the last 7 days'
secrets.
(2) As an optimisation: you can include say the low 4 bits of the day value
in the signature. This would let you select which of the last 16 days the
message could have been sent, and perform only one hash validation. If you
want to validate messages up to 32 days old then you would perform two hash
validations, etc.
i.e.
daycode = utime/86400
dayselect = daycode & 15
signature = hash (sender address + secret + daycode)
append to the message:
* 21 bits of signature
* dayselect (4 bits)
= 25 bits (5 characters of base36)
To validate an incoming message:
rcv_daycode = (daycode & ~15) | rcv_dayselect
rcv_daycode -= 16 if rcv_daycode > daycode
recalculate signature using rcv_daycode and compare the 21 bits
This gives a random signature a 1-in-2 million chance of being correct. The
entire signature is then 5 characters, plus separator and extra domain(s) as
per the SRS spec.
Unlike the original SRS proposal, where signatures could be reused once
every 11 years, signatures would not be recycled at all here, except for
random events once every 2^21 days (5,745 years) on average.
The SRS spec also omits an optimisation where the sender is signed by the
same domain, i.e. you could have
srs+a83cd+user(_at_)source(_dot_)com
(equivalent to srs0+a83cd+source(_dot_)com+user(_at_)source(_dot_)com). This
would be useful
if all outgoing mail is signed when relayed via a smarthost.
Regards,
Brian.