I have a couple of thoughts about the SRS E-mail format, while it's still
fluid enough to be changed.
(1) Why not combine the timestamp and crypto hash into a *single*, opaque
authentication stamp?
srs0+sssss+domain.com+user@domain2.com
^^^^^
replaces +ttt+hhh+
(This field probably contains both a timestamp and authentication hash, but
we don't reveal it as two separate parts)
My reasoning is this makes it more flexible: the sender is entitled to use
any timestamp-encoding and/or hash-validation scheme which they choose.
Other machines handling the mail are unlikely to make use of the timestamp
part by themselves, and also an explicit timestampt is information which
could be useful to spammers. So why pass it in the clear?
Furthermore, it allows the sender to use whatever character set or encoding
they choose, as long as it does not include '+'. So we can end the holy wars
about base64 vs base36 vs base32; implementations can choose whichever they
like. Equally there are no holy wars about the best timestamp format, as
each implementation can choose their own.
It also saves a character or two in the LHS. Comments?
(2) The difference between srs0 and srs1 is the presence of an extra
forwarding host, so the two formats could be unified by including an
explicit empty field in srs0. e.g.
srs+stamp+forwardhost+orighost+user
=>
srs+abcdef++domain1+user@domain2 # "srs0"
srs+abcdef+domain2+domain1+user@domain3 # "srs1"
The length of an srs0 LHS is unchanged, and srs1 is one character shorter.
By explicitly saying "empty fields are equal to the RHS domain", you also
allow a third format:
srs+abcdef+++user@domain1
This would be useful for people who just want to sign their outgoing mails
using SRS to prevent joe jobs, with a minimum increase to the size of the
username.
Rewriting SRS addresses on forwarding is trivial:
- if the orighost field is empty, copy the RHS there
- else if the forwardhost is empty, copy the RHS there
(3) Not really a serious suggestion, but taking this to it's logical
conclusion, you might also just drop "srs", and treat any address which
starts with '+' and contains four or more '+'s as SRS signed:
+abcdef+++user@domain1
That depends how many people are likely to be using addresses containing
four or more '+'s already, which I guess is minimal :-) And as a final
option, if you were prepared to parse the LHS from right-to-left you could
turn the format around:
user+++abcdef@domain1
user+domain1++abcdef@domain2
user+domain1+domain2+abcdef@domain3
But keeping the 'srs+' tag does allow for future changes, so it's probably
worth keeping. So I'm not too bothered about (3), but I think (1) and (2)
are worth considering.
Regards,
Brian.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
fluid enough to be changed.
(1) Why not combine the timestamp and crypto hash into a *single*, opaque
authentication stamp?
srs0+sssss+domain.com+user@domain2.com
^^^^^
replaces +ttt+hhh+
(This field probably contains both a timestamp and authentication hash, but
we don't reveal it as two separate parts)
My reasoning is this makes it more flexible: the sender is entitled to use
any timestamp-encoding and/or hash-validation scheme which they choose.
Other machines handling the mail are unlikely to make use of the timestamp
part by themselves, and also an explicit timestampt is information which
could be useful to spammers. So why pass it in the clear?
Furthermore, it allows the sender to use whatever character set or encoding
they choose, as long as it does not include '+'. So we can end the holy wars
about base64 vs base36 vs base32; implementations can choose whichever they
like. Equally there are no holy wars about the best timestamp format, as
each implementation can choose their own.
It also saves a character or two in the LHS. Comments?
(2) The difference between srs0 and srs1 is the presence of an extra
forwarding host, so the two formats could be unified by including an
explicit empty field in srs0. e.g.
srs+stamp+forwardhost+orighost+user
=>
srs+abcdef++domain1+user@domain2 # "srs0"
srs+abcdef+domain2+domain1+user@domain3 # "srs1"
The length of an srs0 LHS is unchanged, and srs1 is one character shorter.
By explicitly saying "empty fields are equal to the RHS domain", you also
allow a third format:
srs+abcdef+++user@domain1
This would be useful for people who just want to sign their outgoing mails
using SRS to prevent joe jobs, with a minimum increase to the size of the
username.
Rewriting SRS addresses on forwarding is trivial:
- if the orighost field is empty, copy the RHS there
- else if the forwardhost is empty, copy the RHS there
(3) Not really a serious suggestion, but taking this to it's logical
conclusion, you might also just drop "srs", and treat any address which
starts with '+' and contains four or more '+'s as SRS signed:
+abcdef+++user@domain1
That depends how many people are likely to be using addresses containing
four or more '+'s already, which I guess is minimal :-) And as a final
option, if you were prepared to parse the LHS from right-to-left you could
turn the format around:
user+++abcdef@domain1
user+domain1++abcdef@domain2
user+domain1+domain2+abcdef@domain3
But keeping the 'srs+' tag does allow for future changes, so it's probably
worth keeping. So I'm not too bothered about (3), but I think (1) and (2)
are worth considering.
Regards,
Brian.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com