Jim Ramsay [EMAIL PROTECTED] wrote:
It may be important for TMDA to know about what the final verdict on this is, as it may change the way TMDA would operate if DELIVERY is set to forward to an email address.
We may actually have to look at implementing SRS for those wanting to forward emails to SPF/SRS-enabled servers. I don't know if there are any yet, but it may be important in the not-too-distant future as the SRS spec solidifies and people start using it.
Well to be honest TMDA will most likly be the easiest to support correctly
due to it already having cryptkey and all the required methods for
creating a secure cookie.
Yes, but it won't be "real SRS", just a TMDA knockoff. Basically we'll want to follow the spirit of SRS and not the RFC, such as it is now:
We need to have a config variable (like REWRITE_FORWARD_ENVELOPE) which (when enabled) rewrites the outgoing envelope to a tagged secure envelope such that if it bounces, TMDA can convert it back to the original envelope.
I suggest a format like:
<realuser-plus-extensions>-<tagname>-<encryptedsender>@tmda.host.name
Where:
<realuser-plus-extensions> corresponds to the .qmail file ~realuser/.qmail-plus-extensions-default from where TMDA is run
<tagname> is something like 'fwdsecure' so TMDA knows what sort of address it is and doesn't try to challenge it
<encryptedsender> is the original envelope sender, somehow encrypted with the user's CRYPT_KEY so it is not forgeable or readable, but TMDA can decrypt it if it gets a bounce with it
But to be honest SRS is writen to be used the MTA level, the bounce-<address>- part makes it so, at least with qmail. I can not think of a way to make it work within a qmail account without some patching on the side of MTA side of things.
True. More to the point, I think it's written specifically for email-forwarder sites like pobox.com. Also the current SRS RFC-draft would make it quite difficult for only some users to use it, because of the 'bounce-' at the front, which is why I suggested the format above which is more compatible with the way TMDA currently works.
-- Jim Ramsay
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
