Liste des Groupes | Revenir à cm sendmail |
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.
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);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.
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.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.
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 testThat 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.
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.
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.
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.
Les messages affichés proviennent d'usenet.