Found this going through my pymilter TODO list:
Implement RRS - a backdoor for non-SRS forwarders. User lists non-SRS
forwarder accounts, and a util provides a special local alias for the
user to give to the forwarder. Alias only works for mail from that
forwarder. Milter gets forwarder domain from alias and uses it to
SPF check forwarder.
The encoding is like SRS - but for recipients.
For instance, blockbuster.com sends email with a MAIL FROM
of custhelp.com from IPs not listed in the custhelp.com SPF record.
This effectively makes blockbuster.com a non-SRS forwarder.
So, I change the email address registered with them to:
RRS=IHBf67rW=blockbuster(_dot_)com=user(_at_)example(_dot_)com
The hash signature prevents a spammer from sending mail with
arbitrary MAIL FROM to
RRS=????????=spammer(_dot_)com=user(_at_)example(_dot_)com(_dot_) They have to
know the secret to generate a valid RRS alias.
Now, when email arrives to that address, the SPF check is done against
blockbuster.com - even though the MAIL FROM says custhelp.com - and
the mail is delivered to user(_at_)example(_dot_)com(_dot_) This is a much
more controlled
workaround than accepting SPF FAIL for custhelp.com - which has a perfectly
good SPF record.
I bring this up, because it is a solution to handling per-user
non-SRS forwarders that does not involve a separate database. However,
once an RRS signature is issued, there is no way to un-authorize a non-SRS
forwarder without resorting to a block list.
Comments? Other weaknesses?
P.S. Obviously, a database could map 'code(_at_)example(_dot_)com' to
('forwarder.com','user(_at_)example(_dot_)com') for the same effect.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.