On Thu, Dec 14, 2006 at 09:57:55AM +0100, Matthias Waffenschmidt wrote:
> > When this happens the message hangs out in the queue (waiting for a retry
> > timer to exipre?). But it seems as though the recipient of the message is
> > still set to the original recipient, rather than the new recipients
> > specified by the deliver command, because if a queue run starts, the message
> > is delivered to its original recipient:
>
> This is a wild guess because you have only showed us parts of your
> filter file, but it would explain the behaviour you are experiencing:
>
> Does your filter test for first_delivery earlier and not even reach
> the deliver commands?
Hi,
Thanks for the response. No, I don't test for first_delivery anywhere in
the system filter (I didn't include the entire filter because its really
long and confusing), but I do have the following at the top of the filter
way before the deliver commands that I'm having problems with:
if $h_to: matches
"(?:scam@???|admin@???|reports@???|pirt@???|reportphishing@???|abuse@)"
then finish endif
I change the To: header in the scam message that I'm redirecting via the
deliver command to include the address of the recipients - so it would
match the condtion.
However I don't think that this is the problem. All this conditional does
is to cause the processing of this message that happens during the queue
run to exit the sysetm filter sooner by use of the "finish" command. As I
understand it, this means that the delivery routines are then run causing
the message to be delivered to all of its recipients. My problem is that
the mail is still be delivered to the original recipient. It is not sent to
the new recipient for which the delivery failed.
This doesn't seem right because the whole point of the deliver command is
that the message is sent to the new address specified. If this occurs then
then, according to the filter.txt docs:
"If at least one significant delivery is set up, the filter is considered
to have handled the entire delivery arrangements for the current address,
and no further processing of the address takes place."
and, later,
"The filter just defines what deliveries are required for one particular
addressee of a message. The deliveries themselves happen later, once Exim
has decided everything that needs to be done for the message."
As my filter contains a "save" command and a couple of "deliver" commands
to add new addresses to the recipient's list and then a "seen finish" - all
of which are significant actions - it should, as I understand things, cause
the mail to be forwarded to the new addresses (which it does) and then to
stop processing the message due to the seen finish (which it does). As
the message ID in the log file doesn't change, it seems that the deliver
command is forwarding the message to the new recipients as though they are
just part of the recipient's list, rather than creating a new message.
That's fine, except that when a message can't be delivered and it is left
in the queue for a retry attempt alter, the message appears not to know
that the delivery attempt is for a new recipient. As the message is
delivered to the original recipient (and only the original recipient) it
appears that it must have kept the original recipient's list and not
replaced the OR with the NR as the documentation indicates it will when
it says that the original recipient is ignored.
I actually just changed my settings to block mail to these two mail servers
so that mail will "fail" to get there. As annoying as scammers are at least
there isn't a shortage of mail, so within a few minutes a mail had turned
up and, sure enough it couldn't get through:
2006-12-14 13:06:45 1Guuyi-00027W-NH <= service@???
H=(correct.go.th) [203.156.136.66] P=esmtp S=15868
id=200612141730.kBEHUA96018547@???
2006-12-14 13:06:46 1Guuyi-00027W-NH I> BAD PHISH:
F="PayPal"<service@???> SIP=203.156.136.66 SH= R=Forged sender
("PayPal"<service@???>)
2006-12-14 13:06:46 1Guuyi-00027W-NH original recipients ignored
(system filter)
2006-12-14 13:06:47 1Guuyi-00027W-NH => /tmp/spool/unprocessed_scams/
<system-filter> T=system_filter_save_directory
2006-12-14 13:06:48 1Guuyi-00027W-NH => pirt@??? <system-filter>
R=dnslookup T=remote_smtp H=mail.castlecops.com [66.227.46.235]
2006-12-14 13:06:48 1Guuyi-00027W-NH => reports@???
<system-filter> R=dnslookup T=remote_smtp H=banksafeonline.org.uk
[83.138.191.36]
2006-12-14 13:06:49 1Guuyi-00027W-NH => reportphishing@???
<system-filter> R=dnslookup T=remote_smtp H=ikmta.ironkey.com
[69.90.211.76]
2006-12-14 13:06:52 1Guuyi-00027W-NH mail2.netcraft.com [212.95.252.15]
Connection refused
2006-12-14 13:06:52 1Guuyi-00027W-NH == scam@??? <system-filter>
R=dnslookup T=remote_smtp defer (111): Connection refused
2006-12-14 13:07:01 1Guuyi-00027W-NH => admin@???
<system-filter> R=dnslookup T=remote_smtp H=smtp.ilisys.com.au
[203.202.10.154]
2006-12-14 13:07:05 1Guuyi-00027W-NH => spoof@??? <system-filter>
R=dnslookup T=remote_smtp H=smtp1.sc5.paypal.com [64.4.244.74]
And the corresponding -H looks like the following.
1166119604 0
-helo_name correct.go.th
-host_address 203.156.136.66.43993
-interface_address 63.97.115.194.25
-received_protocol esmtp
-aclm 0 0
-body_linecount 266
-host_lookup_failed
YY pirt@???
NY /tmp/spool/unprocessed_scams/:system-filter
NN admin@???
YY reports@???
NN reportphishing@???
NN spoof@???
1
XX@???
219P Received: from [203.156.136.66] (helo=correct.go.th)
by mail2.hagenhosting.com (envelope-from
<service@???>)
with esmtp (Exim 4.63)
id 1Guuyi-00027W-NH
for XX@???; Thu, 14 Dec 2006 13:06:45 -0500
199P Received: from User (corp-200-105-227-46-uio.punto.net.ec
[200.105.227.46])
(authenticated bits=0)
by correct.go.th (8.12.11/8.12.11) with ESMTP id kBEHUA96018547;
Fri, 15 Dec 2006 00:30:29 +0700
056I Message-Id: <200612141730.kBEHUA96018547@???>
035* From: "PayPal"<service@???>
063* Subject: Your payment has been sent to sales@???
038 Date: Thu, 14 Dec 2006 19:41:00 +0200
018 MIME-Version: 1.0
049 Content-Type: text/html;
charset="Windows-1251"
032 Content-Transfer-Encoding: 7bit
014 X-Priority: 1
024 X-MSMail-Priority: High
051 X-Mailer: Microsoft Outlook Express 6.00.2600.0000
057 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
078* NSubject: [SCAM REPORT] Your payment has been sent to sales@???
046 X-Original-From: "PayPal"<service@???>
016 X-Original-To:
077 Subject: [SCAM REPORT] Your payment has been sent to sales@???
036 Return-path: abuse@???
031 Sender: abuse@???
029F From: abuse@???
152T To: <scam@???>, <admin@???>, <reportphishing@???>, <pirt@???>, <reports@???>
023T To: <spoof@???>
The original recipient's address is listed here as XX@???. Reading
through the spec.txt file indicates that the message knows it has been
delivered to all of the addresses in
YY pirt@???
NY /tmp/spool/unprocessed_scams/:system-filter
NN admin@???
YY reports@???
NN reportphishing@???
NN spoof@???
(which it has), and that the recipient list is:
1
XX@???
my customer's address. This is why it gets sent to that address, but it
doesn't explain how it gets to be there because the deliver commands (and
the save command and the seen finish) should cause this address to be
ignored because they're not prefixed by "unseen" and thus are significant
deliveries, which should cause the original recipient to be ignored and for
the additional recipient's to be added. Those deliveries that were
successful caused the recipients to be added to the "non-recipients tree",
as they should be, but the failed delivery address (netcraft's address)
wasn't added to the list of the message's recipients, and the original
recipient has been left on that list when it should not be because a
significant delivery occurred.
If this message had been forwarded to all recipients successfully then
after those forwards are delivered Exim finished handling the mail, without
sending it on to the original recipient. It therefore makes no sense that
if the delivery of a forward fails, causing the message to be queued for a
later retry attempt, that the next delivery attempt causes it to be sent to
the original recipient rather than the recipient for which the forward
failed. It seems that the correct response would be for a deliver command
which fails to add that address to the recipient's list (unless its an
"unseen" delivery)?
Am I simply misunderstanding things, or is this a bug of some sort? Is
there an alternative I can use? Maybe to make the deliveries unseen so that
if they fail like this it won't hold the message in the queue (as its not
essential that they be resent, but it is essential that it doesn't reach my
customer)
I'm freezeing these mails now so that if this happens it won't end up going
to my customers - they get pretty confused by them because it seems like
its a scam mail being sent by our mail server yet there are big warnings
everywhere about it being a scam.
Thanks for your help.
Colin.
--
"Developers are like artists; they produce their best work if they
have the freedom to do so" - Werner Vogels, CTO Amazon.com
