logs archiveIRC Archive / Freenode / #exim / 2015 / August / 18 / 1
qmr
I'm having trouble with system wide filter, can someone help me out?
http://pastie.org/pastes/10357658/text?key=zhjl1oaxencxqqxfi9zy6g
^ that's what I've done so far. tacked a couple variables on to exim config, updated / restarted, and made that filter above, but testing it never passes
Ok, testing with exim instead of sendmail the filter now passes. but it's still being ignored by mail system at large for some reason
henk
qmr: Read the debian specific documentation to learn about the debian specific config handling: https://github.com/Exim/exim/wiki/DebianExim4
qmr
looking at this all again I think maybe I'm going at it wrong way... these messages are being sent, not received. can I apply filters to outgoing messages?
jgh_
at the exim level, all messages are received, then sent. You're asking about a higher level. distinguishing _where_ they will be sent
henk
ah, you dont want to read &
but you should. guessing doesnt really work that well with exim and smtp & both very complex topics and debians configuration method is easy to misunderstand as well & so do yourself and us a favor and read stuff instead of guessing wildly.
qmr
I'm reading now. but good on you for assuming the worst.
henk
wasnt an assumption, but an induction
hs12
Hi, I need some clarification. Until now I thought, Exim *always* does a delivery attempt when the message is received. Independend on any retry rules. If that attempt fails, the retry rules and further queue runners are responsible. Am I wrong?
jgh_
there's cmdline switches and optinos to modify that
         

hs12
Yes, default.
exim -bd -q1m and no control = queue .. and so on
jgh_
default, yup you're right
hs12
So I *should* see a delivery attempt. Even if there is a transport error in the retry file?
jgh_
assuming defaults... but most people set things like queue_only_load...
mmm, actually, maybe I'm wrong
hs12
If I grep -R my config dir, the only occurenc of 'queue' is '-queue_run +queue_time' in the log_selector
So am I.
jgh_
if the target host has been unresponsive, do we avoid an immediate try?
hs12
At a first glance into the spec I couldn't find some notice about that.
(But can reproduce the segfault bug)
jgh_
(good)
hs12
from spec of 4.82: If there have been previous temporary failures and no host has
reached its retry time, no delivery is attempted, whether in a queue run or
not. See chapter 32 for details of retry strategies.
So it's fine if there is no immediate delivery attempt.
And I was wrong all the time :(
jgh_
and me
hs12
I'll double check it, because two people can't be wrong.
:)
MASHtm
jgh_: about 1671 .. I was able to produce coredumps...
smtp_are_same_identities() get's called with a message-id which is already delivered and removed from spool
...also causing the "Spool file .... not found" messages.
jgh_
hs12 see this ^^^
MASHtm
I have coredumps with full debug info.... interested?
jgh_
so how was that id picked up, becomes the question
MASHtm
I was able to reproduce that by putting some known MX hosts into iptables DROP to cause timeouts... then I collected some mails in the queue
jgh_
adding that repeat-by info to the bug would be good, I think
MASHtm
... after removing the DROP i waited for the next queuerunner and *boom* two of four mails crashed the delivery process
interestingly .... the two messages which crashed had a different domain pointing to the same MX hosts.
the NULL in the sender address is coming from the missing spool file IMO
jgh_
sounds plausible... if the id was remembered from some earlier grab, then the fix would be just noting that the spool file read (open?) failed
MASHtm
the question is why transport_check_waiting() tries to check with a already deleted message ID?
ah, ok... the logs show ... the first queuerunner delivered two of four mails successfully... a second queuerunner running 2 minutes later tried to find the same old queuefile and crashed.
...to be correct.... not a second queuerunner. the emails which crashed were fresh and crashed on the first immediate delivery attempt.
         

jgh_
starting to wonder if a39bd74d3e94 broke this; it was playing in transport_check_waiting()
any chance of a bisect?
I realise it's a load of effort
MASHtm
I still try to get all info out of my logs... putting it together in a comment for 1671
jgh_
thanks
mrochford
When sender_verify is done. What is it actually checking?
I wasnt able to find anything specific in the docs
http://www.exim.org/exim-html-3.20/doc/html/spec_45.html#SEC804
henk
exim 3.20? are you sure you are using that?
mrochford
hmm
no no . let me look at the latest docs silly me.
« prev next »