Re: sender rewrining advice

On 3/23/24 07:53, none wrote:

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.

Well, pause for a moment and remember how SRS was(n't) received by the email community at large.
Many poo poo SPF, especially -all, and most people poo poo SRS as a retroactive hack and evidence that SPF is broken.
I'm from a different camp wherein forwarding an email list are SMTP terminations and that a different message leaves those entities.

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.

I think this is a reflection of what the community thinks of SRS.  It wasn't until the last 3-5 years that people have started to realize that ya, rewriting sort of is needed after all.

Do you know if milters are allowed access to rewrite the envelope?

I don't know.  I believe so.  I know of a milter that can silently add a BCC.  That's part of 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 know.  The label on the tin indicates that it would be re-written.  But I suspect that's once per envelope.  As such I'd think that the message would be queued and delivery re-tried using the same address (for that given envelope) if something like grey listing or communications failure happened.

I don't really get why you even need to hash this, aside from trying to make the envelope shorter.

My understanding is that the hash offers a modicum of security to prevent (for some value) someone reversing your SRS mechanism and sending messages to your server that your server would end up sending back out as spam.  I think that it's mostly anti-abuse / anti-reply.
If I know your secret hash seed I could use that to generate an SRS that your system would trust, reverse the SRS and pass the message on to the intended destination as if it originated from your server.

I think I would change this to something like identifying my local ip ranges/network. I think that is easier to maintain.

I think that you are thinking something different.

This way you already prevent local email from being rewritten.

I don't think so.  The email that originates from my server is using envelope domains that are authorized to do so from my server.  I don't /need/ to rewrite them.  I could rewrite them from <user>@example.net to <SRS...>@example.net, but that's unnecessary.  There's also the possibility of ending up with a loop if you're not careful how you code things.

More efficient would be not to have every envelope send external but have sendmail already select which ones need to be rewritten.

That's what the rule I called out using class w does.  If the email is not being delivered locally, then it is being delivered remotely.  If the envelope from isn't us, it needs to be rewritten.

Another way would be use the results from an earlier done spf test

That would imply more state and be more complex code.  Conversely the "if the destination isn't local and the source isn't local, then rewrite the source" logic is relatively simple to do in Sendmail rules.
N.B. that no state about previous tests needs to be referenced. Especially if the tests are done outside of Sendmail proper via a milter.

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).

Bounces end up at the original sender.  It's just that the bounce comes back to your server and your server forwards the bounce to the original sender.
This is also why there is a seed in the hash, to make sure that only email that your server rewrites pass the hash test and thus passed through your server.  --  Prevent your server from being used as a relay.

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.

That would be an information disclosure leak.
There is also no standard way for this to be disclosed.
What's more, with no standard, there is no software to extract that non-existent standard and send the bounce directly.
Aside:  Do some reading on SRS as it's my understanding that SRS0 vs SRS1 (or maybe SRS1 vs SRS2 -- I need more caffeine) as a short cut to avoid some of the rewriting.  --  That being said, I don't think I've ever seen the SRS1 (or SRS2) used in the wild.  Usually one set of rewriting is sufficient for delivery based on what I've seen.

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.

My recollection of LDAP routing is that all hosts in the cluster would consider example.com to be local and that they would know via LDAP routing, which cluster member hosts which mailboxes.
--
Grant. . . .