sendmail mail relay backscatter issue.
 

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.




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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

--
Get your web at Conactive Internet Services: http://www.conactive.com



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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

--
Les Mikesell
lesmikesell@gmail.com




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

sendmail mail relay backscatter issue.
 

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.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos