Hi Folks,
I have a couple of questions which I hope that you will be able to assist with, first some background.
I run a few sendmail servers that run MailScanner/Spamassassin/sendmail (current versions) on Centos 5.4 and Centos 4.8 These boxes accept mail for a large number of domains (6000+) scan the mail removing spam and then forward the ham to another server for delivery. I am attempting to stop any backscatter that these servers cause by only accepting mail for specific users@domain or for domains with a catch-all account.
I currently use /etc/mail/access.db as the access map for the domains, but this allows all mail to be accepted for the domain before the attempting to send it on for final delivery which causes NDR and backscatter for those domains which do not have a catch-all account.
I have looked at adding "To:user@domain RELAY" to the access map and also adding "define(`_RELAY_FULL_ADDR_', `1') " in the sendmail.mc and running make -C /etc/mail but this has no effect on the sendmail.cf file. My understanding is that if I can get sendmail to accept this undocumented feature then all will be fine as I will be able to use the access map to allow mail to those specific users as well as entries of the type "domain RELAY".
My first question is: Does anyone have any ideas as to why I wouldn't be able to have this change reflected in sendmail.cf?
My second question is: Does anyone have any ideas on how to utilise access map and relay-domains to achieve the same thing?
Thanks for your time and assistance.
Simon.
Simon Billis wrote:
Hi Folks,
I have a couple of questions which I hope that you will be able to assist with, first some background.
I run a few sendmail servers that run MailScanner/Spamassassin/sendmail (current versions) on Centos 5.4 and Centos 4.8 These boxes accept mail for a large number of domains (6000+) scan the mail removing spam and then forward the ham to another server for delivery. I am attempting to stop any backscatter that these servers cause by only accepting mail for specific users@domain or for domains with a catch-all account.
I currently use /etc/mail/access.db as the access map for the domains, but this allows all mail to be accepted for the domain before the attempting to send it on for final delivery which causes NDR and backscatter for those domains which do not have a catch-all account.
I have looked at adding "To:user@domain RELAY" to the access map and also adding "define(`_RELAY_FULL_ADDR_', `1') " in the sendmail.mc and running make -C /etc/mail but this has no effect on the sendmail.cf file. My understanding is that if I can get sendmail to accept this undocumented feature then all will be fine as I will be able to use the access map to allow mail to those specific users as well as entries of the type "domain RELAY".
My first question is: Does anyone have any ideas as to why I wouldn't be able to have this change reflected in sendmail.cf?
My second question is: Does anyone have any ideas on how to utilise access map and relay-domains to achieve the same thing?
Thanks for your time and assistance.
One approach here if it is practical to collect/maintain all of the valid recipient addresses is to build a virtuser table with a default reject for each domain the relay handles plus the list of all valid addresses. This is very efficient if you can automate the table updates or the user base is stable.
Another would be to use MimeDefang as the framework instead of mailscanner. It has an option to check recipient addresses via smtp to the delivery servers before accepting. You may have to write a snippet of perl to get that right for multiple domains (that's a feature...). This is less efficient but works in real time against the addresses that will be accepted for delivery.
Mike wrote:
Simon Billis wrote:
<snip>>
I run a few sendmail servers that run MailScanner/Spamassassin/sendmail (current versions) on Centos 5.4 and Centos 4.8 These boxes accept mail for a large number of domains (6000+) scan the mail removing spam and then forward the ham to another server for delivery. I am attempting to stop any backscatter that these servers cause by only accepting mail for specific users@domain or for domains with a catch-all account.
running make -C /etc/mail but this has no effect on the sendmail.cf file. My
Does it not give output? Have you tried adding -d? <snip>
Another would be to use MimeDefang as the framework instead of mailscanner. It has an option to check recipient addresses via smtp to the delivery servers before accepting. You may have to write a snippet of perl to get that right for multiple domains (that's a feature...). This is less efficient but works in real time against the addresses that will be accepted for delivery.
I would question how "real time" that would be for every email for 6k+ domains. If a few have a large client base, or are expecting responses from a mass emailing, it might start to take a *while*, unless you've got pretty heavy duty equipment and networking.
mark
m.roth@5-cent.us wrote:
Mike wrote:
Simon Billis wrote:
<snip>>
I run a few sendmail servers that run MailScanner/Spamassassin/sendmail (current versions) on Centos 5.4 and Centos 4.8 These boxes accept mail for a large number of domains (6000+) scan the mail removing spam and then forward the ham to another server for delivery. I am attempting to stop any backscatter that these servers cause by only accepting mail for specific users@domain or for domains with a catch-all account.
running make -C /etc/mail but this has no effect on the sendmail.cf file. My
Does it not give output? Have you tried adding -d?
<snip> > Another would be to use MimeDefang as the framework instead of > mailscanner. It has an option to check recipient addresses via smtp to > the delivery servers before accepting. You may have to write a snippet > of perl to get that right for multiple domains (that's a feature...). > This is less efficient but works in real time against the addresses that > will be accepted for delivery.
I would question how "real time" that would be for every email for 6k+ domains. If a few have a large client base, or are expecting responses from a mass emailing, it might start to take a *while*, unless you've got pretty heavy duty equipment and networking.
It's the same thing the downstream server is going to have to repeat in just a moment anyway, but this time it doesn't have to do the other steps. If you are close to capacity already it might push you over the edge - and be worth scripting a way to maintain that frontend virtuser table that makes it a near-instant hash lookup for the relay sendmail. But for the relay it will be a win either way to avoid the much heavier load of spam-scanning stuff to invalid recipients and making the downstream servers construct bounces.
Hi,
I would question how "real time" that would be for every email for
6k+
domains. If a few have a large client base, or are expecting
responses
from a mass emailing, it might start to take a *while*, unless you've
got
pretty heavy duty equipment and networking.
It's the same thing the downstream server is going to have to repeat in just a moment anyway, but this time it doesn't have to do the other steps. If you are close to capacity already it might push you over the edge - and be worth scripting a way to maintain that frontend virtuser table that makes it a near-instant hash lookup for the relay sendmail. But for the relay it will be a win either way to avoid the much heavier load of spam-scanning stuff to invalid recipients and making the downstream servers construct bounces.
I hadn't looked at it like that, you may be right, the reduction in scanning may provide enough capacity to handle the additional workload from perl. I think that I would prefer to have sendmail do the "rcpt to:" rejection utilising a map as this I think will be the fastest method, so I'll check out the virtusertable approach.
Thanks
S.
On 2/4/2010 9:09 AM, Simon Billis wrote:
Hi,
I would question how "real time" that would be for every email for
6k+
domains. If a few have a large client base, or are expecting
responses
from a mass emailing, it might start to take a *while*, unless you've
got
pretty heavy duty equipment and networking.
It's the same thing the downstream server is going to have to repeat in just a moment anyway, but this time it doesn't have to do the other steps. If you are close to capacity already it might push you over the edge - and be worth scripting a way to maintain that frontend virtuser table that makes it a near-instant hash lookup for the relay sendmail. But for the relay it will be a win either way to avoid the much heavier load of spam-scanning stuff to invalid recipients and making the downstream servers construct bounces.
I hadn't looked at it like that, you may be right, the reduction in scanning may provide enough capacity to handle the additional workload from perl. I think that I would prefer to have sendmail do the "rcpt to:" rejection utilising a map as this I think will be the fastest method, so I'll check out the virtusertable approach.
I recommend MimeDefang in any case because it uses a very efficient multiplexing technique to let sendmail interleave fast/slow operations with a minimum of long-running perl processes doing the milter operations - and since spamassassin is perl it runs it internally. See page 31 of this pdf: http://www.mimedefang.org/static/mimedefang-lisa04.pdf. And, it lets you control most things in a small chunk of perl instead of fighting with sendmail. There are RPMs for it and clamav at rpmforge.
But, even with MimeDefang it will help to reject everything you can up front. To use virtusertable you have to add the domains you accept for to the local_host_names - which may then require some tweaking to arrange actual delivery, perhaps through mailertable if you aren't already mapping to some other internal host's A record name. Then you can do things like:
# make domain2.com equivalent to domain1.com @domain2.com %1%3@domain1.com # reject domain3.com (might be a CNAME that inherits the MX) @domain3.com error:nouser No such user here
# accept known addresses for domain1.com and set internal target realuser1@domain1.com realuser1@deliveryhost.com realuser2@domain1.com realuser2@deliveryhost.com # reject anything else for domain1.com @domain3.com error:nouser No such user here
Hi,
running make -C /etc/mail but this has no effect on the sendmail.cf file. My
Does it not give output? Have you tried adding -d?
I get an updated sendmail.cf file but the only diff is the header telling me when it was complied.
Adding -d give the following (I've removed the non relevant lines):
No implicit rule found for `sendmail.mc'. Finished prerequisites of target file `sendmail.mc'. No need to remake target `sendmail.mc'. Finished prerequisites of target file `sendmail.cf'. Prerequisite `sendmail.mc' is newer than target `sendmail.cf'. Must remake target `sendmail.cf'. make: Entering directory `/etc/mail' Putting child 0x05474670 (sendmail.cf) PID 10927 on the chain. Live child 0x05474670 (sendmail.cf) PID 10927 Reaping winning child 0x05474670 PID 10927 Removing child 0x05474670 PID 10927 from chain. Successfully remade target file `sendmail.cf'.
Another would be to use MimeDefang as the framework instead of mailscanner. It has an option to check recipient addresses via smtp
to
the delivery servers before accepting. You may have to write a
snippet
of perl to get that right for multiple domains (that's a feature...). This is less efficient but works in real time against the addresses
that
will be accepted for delivery.
I would question how "real time" that would be for every email for 6k+ domains. If a few have a large client base, or are expecting responses from a mass emailing, it might start to take a *while*, unless you've got pretty heavy duty equipment and networking.
I agree - I think that the overhead that perl would impose is too high for this application.
Thanks
S.
On 2/4/2010 9:05 AM, Simon Billis wrote:
Another would be to use MimeDefang as the framework instead of
mailscanner. It has an option to check recipient addresses via smtp
to
the delivery servers before accepting. You may have to write a
snippet
of perl to get that right for multiple domains (that's a feature...). This is less efficient but works in real time against the addresses
that
will be accepted for delivery.
I would question how "real time" that would be for every email for 6k+ domains. If a few have a large client base, or are expecting responses from a mass emailing, it might start to take a *while*, unless you've got pretty heavy duty equipment and networking.
I agree - I think that the overhead that perl would impose is too high for this application.
MimeDefang doesn't start a perl process for each operation, it multiplexes the milter requests from many sendmail processes to a few long-running perl daemons. This is done separately for each milter operation so fast things don't end up waiting for slow things like the spam scans. It doesn't take long for an already-running perl to send a few network packets to verify an address via snmp, but it does add load to the downstream server to do the lookup.
Hi,
One approach here if it is practical to collect/maintain all of the valid recipient addresses is to build a virtuser table with a default reject for each domain the relay handles plus the list of all valid addresses. This is very efficient if you can automate the table updates or the user base is stable.
I have already written the code that updates the access file and the relay-domains file from the final delivery mail server so I think that to create a virtusertable should be simple enough, I'll check the documentation to see how to use the virtusertable in this manner - thanks for the pointer.
Another would be to use MimeDefang as the framework instead of mailscanner. It has an option to check recipient addresses via smtp to the delivery servers before accepting. You may have to write a snippet of perl to get that right for multiple domains (that's a feature...). This is less efficient but works in real time against the addresses that will be accepted for delivery.
I'm not so sure that this is an acceptable overhead - the mail scanners process 2,000,000 messages a day.
Thanks
S.
Simon Billis wrote on Thu, 4 Feb 2010 13:28:04 -0000:
I am attempting to stop any backscatter that these servers cause by only accepting mail for specific users@domain or for domains with a catch-all account.
I believe milter-ahead or smf-sav can be used for this.
Kai
Hi,
Simon Billis wrote on Thu, 4 Feb 2010 13:28:04 -0000:
I am attempting to stop any backscatter that these servers cause by only accepting mail for
specific
users@domain or for domains with a catch-all account.
I believe milter-ahead or smf-sav can be used for this.
Kai
Indeed as can Scam-backscatter, but I'm attempting to not load the backend mailserver with connections if at all possible, due to the number of emails that are received on the antispam machines... (I know that they cache the results of the lookups, but spammers like to send to dictionaries ;-) )
Thanks for the suggestion though :-)
Simon.
Simon Billis wrote on Thu, 4 Feb 2010 17:47:55 -0000:
Indeed as can Scam-backscatter, but I'm attempting to not load the backend mailserver with connections if at all possible,
Yeah, I see. If you fill virtusertable with the valid addresses then you have to give explicit forwards for each existing address, too. If that is fine, then this is surely going to work. It won't work if you want to queue and deliver.
Kai
On 2/4/2010 1:31 PM, Kai Schaetzl wrote:
Simon Billis wrote on Thu, 4 Feb 2010 17:47:55 -0000:
Indeed as can Scam-backscatter, but I'm attempting to not load the backend mailserver with connections if at all possible,
Yeah, I see. If you fill virtusertable with the valid addresses then you have to give explicit forwards for each existing address, too. If that is fine, then this is surely going to work. It won't work if you want to queue and deliver.
What do you mean? Forwarding to the virtuser expansion address should work just like any other address.
Les Mikesell wrote on Thu, 04 Feb 2010 13:52:08 -0600:
What do you mean? Forwarding to the virtuser expansion address should work just like any other address.
It sounds like he didn't forward before, but queue and deliver (e.g. he's the only available MX and queues for a firewalled MX or uses mailertable to get the mail delivered). If he goes to virtusertable he has to fill the table with valid forwards.
Kai
On 2/4/2010 3:31 PM, Kai Schaetzl wrote:
What do you mean? Forwarding to the virtuser expansion address should work just like any other address.
It sounds like he didn't forward before, but queue and deliver (e.g. he's the only available MX and queues for a firewalled MX or uses mailertable to get the mail delivered). If he goes to virtusertable he has to fill the table with valid forwards.
The point would be able to include a default reject rule for each domain, which means that you have to supply valid forwards for all addresses you don't want to reject at the relay. (You could default to forwarding, but that doesn't help with the backscatter issue). But that doesn't change the ability to queue/deliver except that the relay has to accept the domains as local to do the virtuser lookup so the new target has to have a different name for the delivery host. I'm not sure how that relates to your distinction between forwarding and queuing. Sendmail has local and remote addresses, but remote ones all go through the same steps.
Hi,
On 2/4/2010 3:31 PM, Kai Schaetzl wrote:
What do you mean? Forwarding to the virtuser expansion address
should
work just like any other address.
It sounds like he didn't forward before, but queue and deliver (e.g.
he's
the only available MX and queues for a firewalled MX or uses
mailertable
to get the mail delivered). If he goes to virtusertable he has to
fill the
table with valid forwards.
The point would be able to include a default reject rule for each domain, which means that you have to supply valid forwards for all addresses you don't want to reject at the relay. (You could default to forwarding, but that doesn't help with the backscatter issue). But that doesn't change the ability to queue/deliver except that the relay has to accept the domains as local to do the virtuser lookup so the new target has to have a different name for the delivery host. I'm not sure how that relates to your distinction between forwarding and queuing. Sendmail has local and remote addresses, but remote ones all go through the same steps.
I am queuing and delivering using mailertable currently - hence the issue with backscatter as some of the domains do not have catch-all accounts. I am able to produce a list of valid email accounts and domains without a catch-all account so I should be able to create a virtusertable with the required entries to either accept all mail for a domain and then forward it to a specific account (the catch-all account) or to only accept mail for a specific account and then forward it to the same address (is this valid?) by again using mailertable(?). I think that using access.db and relay-domains may also work as needed.
Thanks very much for your help with this and the suggestions it is much appreciated.
Simon.
Simon Billis wrote on Fri, 5 Feb 2010 11:06:36 -0000:
I am queuing and delivering using mailertable currently
I figured something along this line.
- hence the issue
with backscatter as some of the domains do not have catch-all accounts.
Not to mention the extra stress on your system for scanning mails that won't get delivered, anyway. I very much encourage moving away from catch-alls at all. Sometimes it's impossible, but I found that most clients use only a few addresses and can go easily without catch-all. This can reduce the number of mails you have to process dramatically.
I am
able to produce a list of valid email accounts and domains without a catch-all account so I should be able to create a virtusertable with the required entries to either accept all mail for a domain and then forward it to a specific account (the catch-all account) or to only accept mail for a specific account and then forward it to the same address (is this valid?) by again using mailertable(?).
If you go to virtusertable you don't need mailertable at all, it may even be counterproductive/not usable I guess (I'm now mostly using postfix, so my ad- hoc experience with sendmail and mailertable is somewhat dated). But you have to explicitly list all target addresses. Something you didn't need to do before. That is what I wanted to point out earlier. You specify the forwarding address and that's it. You can then either specify a catch-all (just the domain) with an error code or don't specify any. Unless it matches a local alias/user there's then no way to deliver it, so it will get rejected.
I think that using access.db and relay-domains
may also work as needed.
I've never used access.db for relaying/local domains, I always relied on relay-domains. I'm not sure, but I think sendmail takes the first match and then stops scanning access.db. So you might be able to use something like this: To:user1@domain OK (or RELAY) To:user2@domain OK domain REJECT
and then keep your current mailertable method (no need for virtusertable) or use virtusertable expandable forwarding addresses. It's possible, though, that the order gets changed in the compiled map file. Maybe Les knows that better. If that works it might be the best method as it rejects at the first possible processing step.
Kai
Simon Billis wrote:
The point would be able to include a default reject rule for each domain, which means that you have to supply valid forwards for all addresses you don't want to reject at the relay. (You could default to forwarding, but that doesn't help with the backscatter issue). But that doesn't change the ability to queue/deliver except that the relay has to accept the domains as local to do the virtuser lookup so the new target has to have a different name for the delivery host. I'm not sure how that relates to your distinction between forwarding and queuing. Sendmail has local and remote addresses, but remote ones all go through the same steps.
I am queuing and delivering using mailertable currently - hence the issue with backscatter as some of the domains do not have catch-all accounts. I am able to produce a list of valid email accounts and domains without a catch-all account so I should be able to create a virtusertable with the required entries to either accept all mail for a domain and then forward it to a specific account (the catch-all account) or to only accept mail for a specific account and then forward it to the same address (is this valid?) by again using mailertable(?). I think that using access.db and relay-domains may also work as needed.
Sendmail will only look in virtusertable if it considers the address local (i.e. you've added the target domain to local-host-names). That means you'll have to use some other name for the delivery target in the virtusertable expansion side to get it to forward on. Probably whatever you are using in mailertable will work. You might be able to use user@[host.domain] notation or user@[IP_address] there to avoid another MX lookup that would come back to the relay - I'm not sure about that. You'll probably have to do some testing with this part since it is a fairly drastic change to make the targets local - but you can do it one domain at a time.
Les Mikesell sent a missive on 2010-02-05:
Simon Billis wrote:
The point would be able to include a default reject rule for each domain, which means that you have to supply valid forwards for all addresses you don't want to reject at the relay. (You could default to forwarding, but that doesn't help with the backscatter issue). But that doesn't change the ability to queue/deliver except that the relay has to accept the domains as local to do the virtuser lookup so the new target has to have a different name for the delivery host. I'm not sure how that relates to your distinction between forwarding and queuing. Sendmail has local and remote addresses, but remote ones all go through the same steps.
I am queuing and delivering using mailertable currently - hence the issue with backscatter as some of the domains do not have catch-all accounts. I am able to produce a list of valid email accounts and domains without a catch-all account so I should be able to create a virtusertable with the required entries to either accept all mail for a domain and then forward it to a specific account (the catch-all account) or to only accept mail for a specific account and then forward it to the same address (is this valid?) by again using mailertable(?). I think that using access.db and relay-domains may
also work as needed.
Sendmail will only look in virtusertable if it considers the address local (i.e. you've added the target domain to local-host-names). That means you'll have to use some other name for the delivery target in the virtusertable expansion side to get it to forward on. Probably whatever you are using in mailertable will work. You might be able to use user@[host.domain] notation or user@[IP_address] there to avoid another MX lookup that would come back to the relay - I'm not sure about that. You'll probably have to do some testing with this part since it is a fairly drastic change to make the targets local - but you can do it one domain at a time.
I don't think that this is going to work for me then... I'm not able to change the envelope address for the onward delivery. The final mail server will reject the mail if it is not the original email address that I'm accepting the mail for on the mail scanners. Also I understand from the documentation that mailertable is not used for class {w}, i.e. local host names so I think that I'm stuck with the following choices...
1) getting access.db and relay-domains working correctly with: (a) the _RELAY_FULL_ADDR_ feature (b) without the above feature (which works but without the ability to send mail from our networks from email addresses in the access.db map but I think that this is because I need to add specific hosts to the access map.)
2) utilising a milter.
Is this a fair conclusion in your opinion?
Thanks
Simon.
Simon Billis wrote:
Les Mikesell sent a missive on 2010-02-05:
Simon Billis wrote:
The point would be able to include a default reject rule for each domain, which means that you have to supply valid forwards for all addresses you don't want to reject at the relay. (You could default to forwarding, but that doesn't help with the backscatter issue). But that doesn't change the ability to queue/deliver except that the relay has to accept the domains as local to do the virtuser lookup so the new target has to have a different name for the delivery host. I'm not sure how that relates to your distinction between forwarding and queuing. Sendmail has local and remote addresses, but remote ones all go through the same steps.
I am queuing and delivering using mailertable currently - hence the issue with backscatter as some of the domains do not have catch-all accounts. I am able to produce a list of valid email accounts and domains without a catch-all account so I should be able to create a virtusertable with the required entries to either accept all mail for a domain and then forward it to a specific account (the catch-all account) or to only accept mail for a specific account and then forward it to the same address (is this valid?) by again using mailertable(?). I think that using access.db and relay-domains may
also work as needed.
Sendmail will only look in virtusertable if it considers the address local (i.e. you've added the target domain to local-host-names). That means you'll have to use some other name for the delivery target in the virtusertable expansion side to get it to forward on. Probably whatever you are using in mailertable will work. You might be able to use user@[host.domain] notation or user@[IP_address] there to avoid another MX lookup that would come back to the relay - I'm not sure about that. You'll probably have to do some testing with this part since it is a fairly drastic change to make the targets local - but you can do it one domain at a time.
I don't think that this is going to work for me then... I'm not able to change the envelope address for the onward delivery. The final mail server will reject the mail if it is not the original email address that I'm accepting the mail for on the mail scanners. Also I understand from the documentation that mailertable is not used for class {w}, i.e. local host names so I think that I'm stuck with the following choices...
- getting access.db and relay-domains working correctly with: (a) the _RELAY_FULL_ADDR_ feature (b) without the above feature (which works but without the ability to
send mail from our networks from email addresses in the access.db map but I think that this is because I need to add specific hosts to the access map.)
- utilising a milter.
Is this a fair conclusion in your opinion?
What are you currently using in mailertable to get there? If you use [domain] and go to the A record of the same name it might be a problem - but that might work if you try it. Where I've used it, the delivery hosts had their own names that they'd accept in the envelope and the [IP.address] form would also work.
Les Mikesell sent a missive on 2010-02-05:
Simon Billis wrote:
Les Mikesell sent a missive on 2010-02-05:
Simon Billis wrote:
SNIP
What are you currently using in mailertable to get there? If you use [domain] and go to the A record of the same name it might be a problem
- but that might work if you try it. Where I've used it, the delivery
hosts had their own names that they'd accept in the envelope and the [IP.address] form would also work.
Currently I have this in the mailertable: domain(1).com smtp:smtp2.differentdomain.com domain(2).com smtp:smtp2.differentdomain.com ... Domain(n).com smtp:smtp2.differentdomain.com
I think that I'm going to have to test this out and see what happens.
S.
On 2/5/2010 9:53 AM, Simon Billis wrote:
SNIP
What are you currently using in mailertable to get there? If you use [domain] and go to the A record of the same name it might be a problem
- but that might work if you try it. Where I've used it, the delivery
hosts had their own names that they'd accept in the envelope and the [IP.address] form would also work.
Currently I have this in the mailertable: domain(1).com smtp:smtp2.differentdomain.com domain(2).com smtp:smtp2.differentdomain.com ... Domain(n).com smtp:smtp2.differentdomain.com
I think that I'm going to have to test this out and see what happens.
I think it should work to put the smtp2.differentdomain.com in the virtusrtable target as long as the destination accepts that as a local name - and you'd have to go out of your way to avoid it if it is the real hostname or reverse DNS name for the interface.
Les Mikesell sent a missive on 2010-02-05:
On 2/5/2010 9:53 AM, Simon Billis wrote:
SNIP
What are you currently using in mailertable to get there? If you use [domain] and go to the A record of the same name it might be a problem
- but that might work if you try it. Where I've used it, the delivery
hosts had their own names that they'd accept in the envelope and the [IP.address] form would also work.
Currently I have this in the mailertable: domain(1).com smtp:smtp2.differentdomain.com domain(2).com smtp:smtp2.differentdomain.com ... Domain(n).com smtp:smtp2.differentdomain.com
I think that I'm going to have to test this out and see what happens.
I think it should work to put the smtp2.differentdomain.com in the virtusrtable target as long as the destination accepts that as a local name - and you'd have to go out of your way to avoid it if it is the real hostname or reverse DNS name for the interface.
Thanks for your help Les, I'll test it all I think and see what happens.
S.
Dear Les et al,
Thanks for your assistance with this thorny issue. I have finally resolved the problem by utilising the following:
1) I have added to the access map of sendmail all the domains that accept mail for any user, user@domain for those email accounts that exist and hosts that are internal to my network which will send mail via these boxes e.g. internalhost RELAY domain1 RELAY user@domain2 RELAY user@domain1 RELAY
2) I then appended to the end of this file reject lines to reject mail to unknown users e.g.
domain2 REJECT
So now my access map looks like this: internalhost RELAY domain1 RELAY user@domain2 RELAY user@sub.domain1 RELAY domain2 REJECT sub.domain1 REJECT
3) I created a relay-domains file and added to that all the domains that I was going to relay for e.g.
domain1 domain2 etc.
4) restarted sendmail (which rebuilt access.db and allowed sendmail to read in the relay-domains file)
My mail scanners now accept mail for relay/scanning from my internal hosts to any address, from external hosts to mail accounts that exist and to any account at a domain that has a catch all account setup. All other mail is rejected with either "Access denied" or Mailbox for this user is disabled".
All this was achieved using a shell script to find the domains from the qmail server (pop host) and parse the .qmail-* files for each domain and account and build the relevant files. As this is a live service which has the potential to change this script is run via cron on a regular basis to catch the changes. Currently on the pop host this takes about 10 mins to run as it is trawling the filesystem for changes (due to legacy accounts being manually created outside of out provisioning tools negating the opportunity to use the database that exists.)
Thanks again for your help and comments, they were and continue to be very useful.
Rgds
Simon.
-
Kai Schaetzl -
Les Mikesell -
m.roth＠5-cent.us -
Simon Billis