Anthony Campbell wrote:
> On 03 Jan 2010, Eduardo M KALINOWSKI wrote:
>
>> That's strange, your debugging output shows no problem and lists a
>> delivery to a @gmail address.
>>
>> If you have a real output from /var/log/exim4/mainlog, post it. Other
>> debugging options (like a test delivery to @gmail) might help.
>>> Also, if I put "finish", won't that stop procmail being called?
>>>
>> I thought you did not want that. If you want two copies, keep the filter
>> as is.
>>
>>
>
> Actually, I think it IS being sent out - the light on the modem keeps
> flickering. But it doesn't arrive for some reason - rejected by gmail,
> or perhaps by my smarthost?
>
> Here is the relevant part of the log:
>
>
>
> 2010-01-03 12:18:07 1NRPPL-000155-1S <=
> SRS0=8/rE=IM=msn.com=<sendername>@srs.kundenserver.de U=ac P=local
> S=8513473 id=COL114-W498F406CFF682652853E5AB7D0@??? 2010-01-03
> 12:19:31 1NRPPL-000155-1S => .forward@??? R=smarthost
> T=remote_smtp_smarthost H=smtp.ukfsn.org [77.75.108.10]
> X=TLS1.0:RSA_AES_256_CBC_SHA1:32
> DN="C=GB,O=mail.ukfsn.org,OU=GT54261541,OU=See
> www.rapidssl.com/resources/cps (c)08,OU=Domain Control Validated -
> RapidSSL(R),CN=mail.ukfsn.org" 2010-01-03 12:19:31 1NRPPL-000155-1S
> Completed
Anthony,
(Still running 4.69 here, and no procmail, but..)
..that last part, unless you have omitted/truncated seems odd to me.
In the case of the gmail delivery you are finding problematic, it should also
include / end with ... something along the lines of this (extracted from one of
my logged deliveries to gmail):
.....R=dnslookup T=remote_smtp S=3133 H=gmail-smtp-in.l.google.com
[209.85.216.96]:25 C="250 2.0.0 OK 1252480868 11si1808226pxi.1" QT=4s DT=2s
ELSE a 5XX or 4XX denial / deferall ... etc.... where the '250' and 'OK' are
showing in the example.
IOW - a code from the gmail MTA you are hitting is essential if you are to be
sure about the end result.
ABSENT SUCH ... a router/transport set may be doing what it sees as its 'job' -
but that job may not extend to 'final' handshake (delivery or NOT) with the
far-end. My 'archiver' routers are like that - using all-Exim, no procmail.
FWIW, my logging is set up with:
log_selector = +all -all_parents -queue_run -arguments
Wherein the last three '-' entries save a good deal of noise as I trip a
queue-runner every 55 seconds.
Now - that *appears* to be because you are not directly communicating with gmail
in the first place .. (ELSE have picked the wrong example ...)\
;-)
... but you should still see a '250 OK' from the intermnediate smarthost.
You would need acess to the logs of THAT box to see what is happening when it
reaches out to touch gmail..
>
> As regards the last line:
>
> I don't want two copies but I thought I needed that line in order to
> make procmail work for my other mail. Is that wrong?
>
> Anthony
>
Shouldn't matter if you have the logic AND router-sequence 'correct' - EG
whatever routes to gmail should do that, and only that, (no procmail) and only
for the 'chosen' traffic, with all (each) other (category of) traffic handled
differently (procmail AND NOT delivery to gmail .. or 'whatever' fits).
Or BOTH. IF that is your need... but *someone* among the transports must see a
'250 OK' (and log same). It is among the most 'necessary' of all log entries.
NB: procmail is 'good stuff', and an essential tool with less flexible or less
'extensible' MTA - - but not ordinarily needed with Exim, which can be told to
do the needful things internally or with its own toolsets.
Converting to handling things that way (100% Exim), usually makes for much
easier debugging and cleaner logging among other things, so you may wish to
make that investment in time and learning curve. Plenty of examples in this list
archives of equivalants to procmailish handling.
HTH,
Bill Hacker
