Re: sender rewrining advice

What I have is based off of the following, which is now available via Archive.org
 Link - SRS integration with sendmail
  - https://web.archive.org/web/20051221183047/http://srs-socketmap.info/sendmailsrs.htm
 

Yes that is helpful. I have been reading them already quite a few times. I am little surprised that this rewriting requires external support. I thought some functions would be compiled in with sendmail.

 I have sym-links in /usr/share/sendmail/cf/hack directory pointing to the m4 files in the /etc/mail/srs directory.
 Towards the end of my sendmail.mc file I have the following line:
 I'm currently using the perlsrs-old.m4.
     HACK(`perlsrs-old')dnl
 Both perlsrs.m4 and socketmap.m4 rely on the socketmapd.0.31.pl file running as a daemon listening on a local Unix socket.  --  I used this for a while, but abandoned it because I got tired of needing to manually start it after updates.  I should have written an init script, but c'est la vie.
 So I switched to perlsrs-old.m4 which forks a copy of envfrom2srs.pl or srs2envto.pl as necessary.
 I've never had any problems with the overhead of forking the Perl processes.  SpamAssassin, ClamAV, and the IMAP daemon take up FAR more resources than the SRS solution.

I am really surprised there is still so little native support for srs in sendmail or existing milters. Especially when I see you are already addressing this since 2004.
Do you know if milters are allowed access to rewrite the envelope?
new Mail::SRS (Secret => $secret, HashLength => 8, AlwaysRewrite => 1);
Does this make a unique envelope every time? I am using a whitelist, where I can add email addresses. Rewriting constantly with a unique sender would make this useles.
I don't really get why you even need to hash this, aside from trying to make the envelope shorter.

It looks like line 37 of the perlsrs-old.m4 is what references the class w map (where local-host-names gets loaded into).  So I would think that you could create a new class and load contents of a different file into the class and for reference.

I think I would change this to something like identifying my local ip ranges/network. I think that is easier to maintain.
This way you already prevent local email from being rewritten.
More efficient would be not to have every envelope send external but have sendmail already select which ones need to be rewritten.
Another way would be use the results from an earlier done spf test
Seeing this webarchive page also made me think more in general about this. Eg. with bounces, where should these go. I am not really maintaining a local mailbox for this (yet). If they should return to the original sender, would I include possible information that discloses the forward email address or should I filter this out somehow.
I am also rethinking maybe doing something on host A, the mx servers. Maybe instead configuring host B, configure A local. And then have some local rules applied that do the sender rewriting? Forget about DKIM signing these forwards.
mailLocalAddress: test@me.com / test@example.com
mailHost: LOCAL / A.local
mailRoutingAddress: test@guerrillamail.com