I would like to forward messages to external email addresses and apply
sender rewriting. I don't have any experience with this, and was
wondering what a default best practice is.
- on the mx server I want to decide what messages are for local delivery
and what go to external.
Normally I have to first relay the message to a local host, where in the virtualuser table I have an entry to deliver to an email address.
I prefer to skip this. What could I use on the MX host? LDAPRoute?
- I prefer the messages to be routed via the 'OUTGOING' service
Because the MX are not specified in spf records. Assuming that such
envolopes 'SRS0=HHH=TT=example.org=alice@example.com' are still being
checked on spf.
- on the 'OUTGOING' I only have dkim signing
I guess best would be to first do some routing and then on the
'OUTGOING' do the sender rewriting. Anyone already doing something like
this?
I do SRS on recipients that aren't in class w. So the method I'm using wouldn't work for you as things going from MX to LOCAL would be
re-written using the method that I'm using. Though there is a chance
that LDAP routing might change this.
- on the mx server I want to decide what messages are for local
delivery and what go to external.
I'm going to assume that you have an email route (mailertable?) for
things going to LOCAL and a fall back smart host configuration going to OUTGOING.
How are you dealing with the routing to LOCAL today? mailertable and /
or LDAP routing and / or something else?
Normally I have to first relay the message to a local host, where in
the virtualuser table I have an entry to deliver to an email address.
I prefer to skip this. What could I use on the MX host? LDAPRoute?
Please elaborate on what you are doing today.
- I prefer the messages to be routed via the 'OUTGOING' service
Because the MX are not specified in spf records. Assuming that such
envolopes 'SRS0=HHH=TT=example.org=alice@example.com' are still being
checked on spf.
I don't see any problem with sending all messages leaving your
environment via OUTGOING. I'd have to look up to see which is the
better way to do that; fall back smart host or smart host or something
else.
- on the 'OUTGOING' I only have dkim signing
I guess best would be to first do some routing and then on the
'OUTGOING' do the sender rewriting. Anyone already doing something
like this?
You could apply the same type of sender rewriting that I'm doing on your OUTGOING host. Assuming that there is exceedingly little that is
delivered locally while everything else is going off host.
Even if .forward type activity for root et al. on OUTGOING going back to
MX -> LOCAL shouldn't be a problem if it's rewritten via SRS.
yes mailertable, but no fall back at all.
mailertable, only a few entries in LDAP routing
I am not really doing anything yet. I have some people on LOCAL using forwarding, which are starting to generate spf bounces.
But in the near future I would like to offer an email address that is forwarded, that I configure and not some users turning it off/on.
I tested a bit with ldap routing. I would be able to forward remotely
via MailLocalAdress and MailRoutingAddress
test@gmail.com -> test@me.com received at MX -> test@guerrillamail.com
I think it would be nicer if I could skip processing on LOCAL.
There will be email addresses on this @me.com that are just delivered to regular mailboxes on LOCAL.
I have limited experience with smart hosts. Only used in situations
where all traffic is forwarded.
I think I have fair amount of local deliveries also on OUTGOING. What is
the problem with local delivery and SRS?
I thought the SRS milters could be given something like ip ranges to determine what is local and not?
Yes that would be my 2nd point of attention. Handling these userThe way that I'm using SRS, Sendmail looks to see if the recipient email
forwards correctly. But I thought focussing on just forwarding at the MX would be easier for now.
mailertable, only a few entries in LDAP routing
Please elaborate on which you're using when and why.
I think it would be nicer if I could skip processing on LOCAL.
You should be able to forward directly on MX without needing to loop
through LOCAL.
There will be email addresses on this @me.com that are just delivered
to regular mailboxes on LOCAL.
It looks like you are using @me.com as a reference to your own domain,
not Apple's iCloud me.com.
Which system thinks that it is responsible for -- I'm going to say -- @example.com? MX or LOCAL?
If you are using LDAP routing, you can have MX think that @example.com
is local to it. -- I think, based on my understanding.
I'm not using a milter to do SRS. I've got SRS hooked into Sendmail as
part of one of it's rule sets.
- MX is a function, not a host name
- LOCAL is a definition for addresses, much like loopback / 127.0.0.1
in IPv4
- @me.com is an often used domain name that is registered to Apple for their iCloud.
I think that clearer names / identifiers would help this discussion.
Also, please provide the name(s) that Sendmail things are local to each system. Feel free to redact part of them if you want to, but something
like a.example is on ${HOST_PREVIOUSLY_CALLED_MX}, b.example is local to ${HOST_PREVIOUSLY_CALLED_LOCAL}, and c.example is local to ${HOST_PREVIOUSLY_CALLED_OUTGOING}. I think these (place holder) names
are going to quickly become extremely important.
both on MX. LDAP routing when an email destined for host B, should
temporary go to host A.
correct
LOCAL
Ok so for this setup I should create Ldap routing entries like this.
mailLocalAddress: test@me.com / test@example.com
mailHost: (OUTGOING server)
mailRoutingAddress: test@guerrillamail.com
but I have to allow relaying on OUTGOING with something like this in the access map
Connect:(MX server) RELAY
Is it wise to maybe reduce this to only the me.com/example.com or is
there something different.
Would this be possible/better
FEATURE(`blacklist_recipients')
@me.com RELAY
@example.com RELAY
Does MX (host A?) have @example.com in it's relay-domains file (or
somehow otherwise in class R)?
mailLocalAddress: test@me.com / test@example.com
mailHost: B
mailRoutingAddress: test@guerrillamail.com
If I'm correctly picking up what you're putting down you are trying to
say that mail to test@example.com should be forwarded to test@guerrillamail.com and go out via the OUTGOING server?
I'm going to have to dig out the Bat book and re-read about LDAP routing.
---
I'm confident that MX could relay @example.com to LOCAL and where LOCAL
could forward the message to @guerrillamail.com and send it back out.
Aside: LOCAL could send the email via MX which would send it on to
OUTGOING or perhaps LOCAL could send it directly to OUTGOING.
but I have to allow relaying on OUTGOING with something like this in
the access map
Connect:(MX server) RELAY
I think that you can add MX's hostname or IP address to the /etc/mail/relay-domains file.
Can you specify ip ranges there or host domains, so you do not do
envelope rewriting when it is not necessary?
The method that I'm using -- I need to log in and copy some files to
provide examples -- simply applies sender rewriting to any envelope that
is not from a domain that Sendmail is responsible for; /etc/mail/local-host-names (class w).
They look at the sending envelope address and compare it to the /etc/mail/local-host-names (class w).
internet internet
recv. email
| ^
| |
| |
V |
+------------+ +------+-----+
| A | | B |
| mailert +---1-->| auth |
| accessmap | | |
| ldapr | | |
+------+-----+ +------------+
|
|
|
V
+------+-----+
| C |
| |
| virtuser |
| |
+------------+
host a: incomming, mx
host b: outgoing, smtp with user auth
host c: user mailboxes, user@example.com (not test@example.com)
Indeed. I am trying to use email addresses here and not domains. So NDR
are generated on host A / mx server.
I have there, access:
to:test@example.com RELAY
This ldap entry currently makes emails being routed from the mx server A
to the outgoing server B
correct
Yes the above does this currently with ldap routing. But I don't know if
this is the best way to do it.
host C, LOCAL is not in the spf records. I think external access is even blocked. I had spammers by passing spam blocking on the mx / host a and delivering directly to C
ok I made note of this, I will enhance this later.
I am not sure if my outgoing, host b, has access to the
local-host-names. It is still using the same clusterid as host c and can probably access the local-host-names.
But I think in the near future I will create a separate clusterid for
the outgoing, host b.
(Used to have everything in one host)
At some point in the future I would like to secure host b more, so authenticated users can only send out email with their assigned address.
So currently I am able to route from host a to host b the emails send to test@example.com.
How should I go about to enable SRS for senders to test@example.com on
host b?
From memory -- I'll look some time this weekend -- the SRS routine that
I'm using uses the local-host-names file (class w) as part of the test
to determine if envelope senders should be rewritten or not.
I have all of the attached files in the /etc/mail/srs directory.
Let's see if 14 kB of attachments make it through Usenet. }:-) They're text. :-D
Here goes nothing.
N.B. I originally drafted this reply with the files attached, but I've
since removed them and will send them in a follow up. They should be forthcoming shortly.
= $uid;$< = $uid;
I have all of the attached files in the /etc/mail/srs directory.
Let's see if 14 kB of attachments make it through Usenet. }:-)
They're text. :-D
Here goes nothing.
If the message with the attachments that I'm replying to didn't make it
to your news server, let me know.
At some point in the future I would like to secure host b more, so
authenticated users can only send out email with their assigned address.
I'm aware that such is done by some MTAs. I've wondered about doing
that with Sendmail. But then I realized that users were authenticating, thus I would have a good idea (but no guarantee) who, or at least which account, was being used to abuse things. I've not needed to actually go down this path (yet).
I have there, access:
to:test@example.com RELAY
Do you also have a corresponding REJECT?
to:@example.com REJECT
Without the REJECT I would expect Sendmail to accept the message as part
of the relay-domains configuration.
host C, LOCAL is not in the spf records. I think external access is
even blocked. I had spammers by passing spam blocking on the mx / host
a and delivering directly to C
SPF is about the connecting host.
As such, GuerrillaMail.com will see host B as the connecting host and
check it's IP against SPF records.
Depending on your configuration, hosts A, B, and C may need to either
have allow list entries or valid SPF information for each other.
According to mailstats, my server has been averaging 15.5 k messages a
day for the last month (10k min and 19k max). I'm on a small Linode w/
2 GB of memory. -- This really doesn't make an impact and it's not
like it's a big system.
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
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.
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 can't say that I'm surprised. Hoping. Wishful thinking.
Let's see if this comes through.
That is good to hear. I am not processing that much yet, but looking
forward in doing so.
If you like stats, maybe have a look at mailfromd as a milter. I asked
them (Sergey) to add exporter for prometheus, which they did after a
year. Now you can practically log now anything you want.
I think this is a selling point of services like sendgrid and the likes. There are even banks using such services. So I assume they check this, otherwise it would be very easy for scammers to send out phishing emails.
Since I am thinking of developing/adding a business to consumer service,
I am getting a little more interested in this.
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 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.
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.
Afaik it is currently like this, I have to put something in the access
map to allow it through. Either test@example.com or @example.com on
RELAY. Currently I am not using entries like @example.com any more.
I want to prevent as much as possible hosts that are allowed to send out email.
:/ No they seem to have stripped it.
= $uid;$< = $uid;
I can't say that I'm surprised. Hoping. Wishful thinking.
Let's see if this comes through.
Did those make it through?
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.
Yes I have this.
Don't I need to change the spaces to tabs in the m4 files?
Hmmm, I don't really get this. My spf (and maybe even dkim) are still
applied not?
Any receiving host will still check the same example.com spf, as if it
would be a 'regular' envelope.
So I switched to perlsrs-old.m4 which forks a copy of envfrom2srs.pl or srs2envto.pl as necessary.
Ok so I have now a bit of 'test' environment, build an el9 rpm for perl
SRS.
So I need to rewrite test@gmail.com to ...@example.com in order to have
the email accepted by guerrillamail
test@gmail.com -> test@example.com forwarded to test@guerrillamail.com
I assume I can test like this:
[@srs]# perl envfrom2srs.pl test@gmail.com SRS0=Q8cgq6jj=K6=gmail.com=test<@REDACTED.>
This fromdomain/forward domain seems to be hard coded
I prefer this to stay on the domain that is being forwarded. I like to process messages like this
- https://web.archive.org/web/20051221183047/http://srs-socketmap.info/sendmailsrs.htm
The collection of files is basically two versions of very similar solutions. I've used both.
I'm currently using the perlsrs-old.m4.
HACK(`perlsrs-old')dnl
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.
this from the webarchive, was always executing the srs rewriting not?
SEnvFromSMTP
R$+ $: $>PseudoToReal $1 sender/recipient common
R$* :; <@> $@ list:; special case
R$* $: $>MasqSMTP $1 qualify unqual'ed names
R$+ $: $>MasqEnv $1 do masquerading
R$* $: $(make_srs $1 $)
:) I am not really experienced with m4 nor sendmail. Could that be
something like modifying this?
define(`confCW_FILE', `@LDAP')dnl
FEATURE(use_cw_file, `LDAP')dnl
Would it not be an easy sendmail hack to only allow messages going out
that have an envelope domain that matches a domain in this map?
🙂 I am not really experienced with m4 nor sendmail.
receive
|
|
|
|
V
+------------+ +------------+ +------------+
| MX | | OUTGOING | | MX |
| +------>| |----->| |
| accessmap | | | | EXTERNAL |
| | | | | |
+------+-----+ +------------+ +------------+
|
|
V
+------+-----+
| LOCAL |
| |
| virtuser |
| |
+------------+
Hi Grant,
I just wanted to let you know I got this forwarding now working on mx
and do not need to route first to out any more.
I have removed the mailhost from ldap routing.
Would you know of something I could pass as a macro to the milter that
would show if ldap routing is applied/active? If I know this, I could
limit the amount duplicate dns lookups quite a lot.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 36:49:40 |
Calls: | 6,707 |
Files: | 12,239 |
Messages: | 5,353,438 |