Re: [exim] help about max_rcpt

SW & Work SaS wrote:
> Hi to all
>
> I'm rather new to Exim and *nix in general so I've lot to learn
>
> I'm using a vps with cPanel / Exim,
> on the server we have a firewall that warn us every X email sent
> but the check is done only on the "to" and not to "bc/bcc"
> so I would like to split incoming messages to be able to control also these
> cases.
>
> I've seen that exist a way to control the number of bc/bcc in incoming
> messages but RFC requires them to be at least 100
> so I've seen the max_rcpt option.
>
> Following the docs I've added a block to routers
> ===
> mycheckspam2:
> domains = ! +local_domains
> condition = "${perl{checkspam2}}"
> driver = redirect
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 64.94.110.0/24
> allow_fail
> data = "${perl{checkspam2_results}}"
>
> mytrackbandwidth:
> domains = ! +local_domains
> condition = "${perl{trackbandwidth}}"
> driver = redirect
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 64.94.110.0/24
> allow_fail
> verify = false
> data = "${perl{trackbandwidth_results}}"
>
> mydk_lookuphost:
> driver = dnslookup
> domains = ! +local_domains
> #ignore verisign to prevent waste of bandwidth
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 64.94.110.0/24
> require_files = "+/var/cpanel/domain_keys/private/${sender_address_domain}"
> headers_add = "${perl{mailtrapheaders}}"
> transport = my_dk_remote_smtp
>
> mylookuphost:
> driver = dnslookup
> domains = ! +local_domains
> #ignore verisign to prevent waste of bandwidth
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 64.94.110.0/24
> headers_add = "${perl{mailtrapheaders}}"
> transport = my_remote_smtp
>
>
> myliteral:
> driver = ipliteral
> domains = ! +local_domains
> headers_add = "${perl{mailtrapheaders}}"
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 64.94.110.0/24
> transport = my_remote_smtp
> ===
>
>
> and a block to transports
> ===
> my_remote_smtp:
> driver = smtp
> max_rcpt = 1
> # headers_add = "X-Descriptions: my_remote_smtp"
> interface =
> ${lookup{$sender_address_domain}lsearch{/etc/domain_ips}{$value}{$interface_
> address}}
> helo_data = $smtp_active_hostname
>
> my_dk_remote_smtp:
> driver = smtp
> max_rcpt = 1
> # headers_add = "X-Descriptions: my_dk_remote_smtp"
> interface =
> ${lookup{$sender_address_domain}lsearch{/etc/domain_ips}{$value}{$interface_
> address}}
> helo_data = $smtp_active_hostname
> dk_private_key = "/var/cpanel/domain_keys/private/${dk_domain}"
> dk_canon = nofws
> dk_selector = default
> ===
>
>
> looking at exim_mainlog I see the messages are sent using the correct route
> ===
> 2011-10-24 00:17:51 1RI6MY-0006KW-MX<= postmaster@???
> H=host149-103-dynamic.14-87-r.retail.telecomitalia.it (c2d6600)
> [87.14.xxx.xxx] P=esmtpa A=dovecot_login:postmaster@??? S=731
> id=00a401cc91d1$9a215590$e400000a@c2d6600 T="prova2"
> 2011-10-24 00:17:51 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc
> 1RI6MY-0006KW-MX
> 2011-10-24 00:17:55 1RI6MY-0006KW-MX DK: message signed using a=rsa-sha1;
> q=dns; c=nofws; s=default; d=xxxxxxxx.com;
> h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Cont
> ent-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-Sour
> ce:X-Source-Args:X-Source-Dir;
> 2011-10-24 00:17:55 1RI6MY-0006KW-MX => info@??? R=mydk_lookuphost
> T=my_dk_remote_smtp H=mail.xxxxxxxx.it [64.14.xxx.xxx]
> X=TLSv1:AES256-SHA:256
> 2011-10-24 00:17:56 1RI6MY-0006KW-MX DK: message signed using a=rsa-sha1;
> q=dns; c=nofws; s=default; d=xxxxxxxx.com;
> h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Cont
> ent-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-Sour
> ce:X-Source-Args:X-Source-Dir;
> 2011-10-24 00:17:56 1RI6MY-0006KW-MX => xxxxxxxx@???
> R=mydk_lookuphost T=my_dk_remote_smtp H=imp-3.mail.tiscali.it
> [213.205.33.247]
> 2011-10-24 00:17:56 1RI6MY-0006KW-MX Completed
> ===
>
>
> but, using max_rcpt, may be I'm wrong, I expected to see a different
> delivery with a different messageID for each single message, instead the two
> messages of the sample (a "to" and a "cc") are still sent with a single
> messageID

It is not entirely clear where the traffic is being originated. SB

> what am I doing wrong ?

IF the traffic originates within your user pool, AND by direct or
indirect invocation of the Exim binary (users having shell accounts,
using a toolset that provides the 'virtual' equivalent for them,
and/or most, but not all webmail services), THEN you might want to look
at an acl_not_smtp.

ELSE the traffic is submitted from 'strangers' over port 25 OR by your
user group over port 587, either case of which can be handled in acl's,
as there is an smtp 'session' invoked.

Delaying handling until you have already accepted the traffic on-box,
and using router rules is actioning 'whatever' much later in the cycle
than it needs to be.

Ideally, a router/transport should always deliver 'somewhere' and
'somehow' AND NOT 'blackhole' (looks like an open-relay to the dumber
'bots, and they WILL exploit it). ACl-based rejection should have
prevented unwanted traffic reaching routers at all.

Far better to do evaluation and rejection/deferral in one or more 'acl',
as these act DURING the 'live' smtp session, insuring that you:

A) Do not send a DSN to the wrong party as 'backscatter' spam

B) provide 'instant' notification to the connected party, and no other -
whomever they may be.

C) Use fewer CPU resources, disk repostionings, and less storage space
by tossing the junk BEFORE taking in the message-body and queuing it.
(Router/transport sets operate off the queue, and anywhere from
fractional seconds to multiple days AFTER the session has closed - not
during the 'live' near-real-time smtp session-stream)

> or I've misunderstood something ?
>

Only Exim's unparalled ability to perform complex analysis and branching
WITHIN the 'live' smtp session.

This is where Exim differs most from other mainstream MTA, and is a
primary driver for the selection of Exim, hence should be utilized to
the utmost to gain Exim's advantages.

Ex: Apply limiting of simultaneous connections from a given host/IP in
the MAIN section that precedes even the acl's, and limiting count of
recipients in an acl_smtp_recpt clause.

Yes, the RFC - written in gentler times - wants to see at least 100
recipients per message if the envelope asks for that. But few legitimate
ones ever do so nowadays, even on - or most especially on - Mailing
Lists. Most have to either/both limit to small batches ELSE 'randomize'
w/r to destination domain.tld ... or risk being seen as abusive.

Ergo killing spam trumps that '100 per..', has become common at BOTH
ends of a connection, and will hardly ever be a source of complaint in a
world where MOST traffic is for one recipient or a sub-set only of for
example, the full headcount of corporate, departmental, or University
entities.

Even those entities, such as Universiites, that DO have legitimate large
recipient bases will often not want to see 'external' traffic seek such
a broadcast to all-hands at one go. Internally, they can apply different
rules, and/or provide an MLM function as 'gateway' that also allows
saner maintenance of user community changes.

> Thanks in advance for any help you could give
> Best Regards
> Flaviano
>
>

HTH,

Bill
--
韓家標