Don Sceifers wrote:
> I'm sorry Phil, I thought you realized from my original post, we are trying
> to drop a connection on incoming mail when our own domain does not have an
> MX record.
>
> I had gotten the mx_domains=* from you on an earlier post.
>
> Our server is being deluged by people spamming domains that have no valid
> email addresses, but the server doesn't drop them, at least not until it has
> read the content. Unfortunately, that takes a lot of time to do. We were
> trying to sever the connection as soon as we realized the mail would be
> eventually undeliverable.
>
> I have tried reading the documentation, but could not find an example of
> such a thing. Is an ACL what I should be trying to create? Are there boards
> anywhere I could look for examples?
>
> Thanks for any help you can offer.
>
> Don
Don,
That you have such a probem *at all* indicates you are doing something
out of the ordinary - such as hosting or 'parking' a largish number of
websites without mail service on the same IP(s) as site(s) which DO have
smtp service.
Your first line of defense is to separate the mail service to another
(set of) IP(s) so that traffic chasing an A-record-only will hit an IP
that is not even running a port-25 smtp listener.
Both *can* be on the same box, so long as the MTA listens ONLY on the IP
you publish MX RR's for AND NOT on the one that serves <domain>.<tld>
for which you do not provide mail service.
The second line of defense comes at acl_smtp_rcpt, the earliest point at
which the users@??? is known to your server.
If you have sorted the above issue, then a 'require verify = recipient'
will do a verufy-only mode router/transport 'walk' to confirm that at
least one router/transport set can deliver.
That test 'automagically' covers BOTH the <domain>.<tld> AND the
specific user. ($local_part@$domain)
However...
If EITHER you have NOT sorted the above, (A vs MX shedding of unwanted
<domain>.<tld> arrivals)
OR you are doing wild-card, catch-all or similar unfiltered forwarding,
(IOW may not know all 'current' end users) THEN it would be helpful to
use an acl clause that does a hostlist, db, cdb or flat-file search on
the permitted domains.
As in:
deny
!domains = +local_domains
IOW if NOT in the local_domain hostlist, deny.
You will probably still want the 'require verify = recipient', (later)
but placing this clause ahead of it *may* shed the unwanted more cheaply
in terms of CPU cycles & time. At least it should if a short hostlist or
fast CDB lookup is used.
HTH,
Bill Hacker
>
>> -----Original Message-----
>> From: Phil Pennock [mailto:exim-users@spodhuis.org]
>> Sent: Wednesday, December 03, 2008 7:30 PM
>> To: Don Sceifers
>> Cc: 'Exim-users'
>> Subject: Re: [exim] Recipients with no MX record need to drop
>>
>> On 2008-12-02 at 12:43 -0500, Don Sceifers wrote:
>>> Phil,
>>> (or anyone)
>>>
>>> I have tried to get this into our cPanel configuration and I don't
>> know
>>> exactly where to put it. Can you validate that this ACL will drop any
>>> connection trying to deliver to one of our domains that has not
>> defined an
>>> MX Record?
>>>
>>> drop message = That is not a valid email for this domain
>>> mx_domains = *
>> No, it's not an ACL option.
>>
>>> And once again, where is a good spot to drop it in the exim config
>> file.
>>
>> Per my original mail:
>> : Instead look at setting the mx_domains option on your dnslookup
>> router
>> : to specify a list of domain-matching items (eg: *.co.com : *.com.com
>> )
>> : which require an MX record.
>>
>> If you add:
>> mx_domains = *
>> to the dnslookup Router which handles outbound mail, then it will
>> require an MX record (no fallback to A); the normal recipient
>> verification in the RCPT ACL will handle this fine, since the domain
>> should no longer have a Router which accepts mail for it, so the
>> address
>> will be unhandled.
>>
>> Exim ships with documentation called The Exim Specification; it's
>> available online at www.exim.org or in a file called "spec.txt" which
>> your software packages should have installed somewhere. In that, you
>> can search for "mx_domains" to get more detailed information.
>>
>> -Phil
>
>
