On Thu, Feb 19, 2004 at 03:42:43PM -0600, mw-list-spf-discuss(_at_)csi(_dot_)hu
wrote:
(3) The signature expires after a few days, so even if such addresses could
be harvested, they would not be useful in the longer term, distributed on
CD-ROMs etc.
I thought secrets are changed monthly, and the timestamp is not used
when the hash is applied.
No, the hash *is* calculated across the timestamp, to protect it from
forgery. If you were just relying on the secret changing, there would be no
point including the timestamp within the SRS return path at all.
There is no need to change the secret frequently.
This seems to give a full month to play
with the address.
It doesn't.
Is the gain worth the effort: change usual
bouncehandling, demand some parts of an MTA run setuid, etc?
The secret could be world-readable on a box which has no shell users. Mail
configurations can contain other secrets anyway (e.g. secrets for SMTP AUTH,
private keys for certificates), so hiding the secret is really a non-issue.
The gain is *complete* protection from joe-jobbing, and unlike SPF, you get
it instantly. Worth having I'd say; more than SPF in fact.
Do we get more than with dated addresses of TMDA or qconfirm which
work _now_ without requiring the whole internet to switch to them
before they would work?
I don't understand what you're saying here. You can use SRS, or any other
comparable path-rewriting scheme, and nobody else on the Internet has to be
any the wiser.
*If* you are in an SPF world, *and* you are forwarding messages multiple
times, *then* you accrue some benefit by grokking SRS in the intermediate
hops, because you can prevent the address being rewritten multiple times.
(srs0 -> srs1 -> srs1 etc). The document "srs.pdf" explains it well.
Regards,
Brian.