On Friday 14 April 2006 10:37, Jay Lee wrote:
Clive Dove wrote:
The above code is preceeded by a routine that sends cooker mailing list
messages directly to the default mailbox. This is because cooker is a
high volume mailing list which I don't want to feed through spamassassin.
I had posted a message to this list respecting whether it would work to
have set the exitcode to 553. The fetchmail man page states that smtp
return code 553 would cause fetchmail to remove the message with the
server without any attempt at bouncing it.
I received no reply so I went with simply returning exitcode 0 so that
fetchmail would treat the message as having been delivered.
I would have preferred the other return code in the hope that I could get
the fetchmail log to leave a trail for any rejected messages. The
.maillog file does not leave such a trail.
You're confused. The SMTP code has nothing to do with the maildrop
code. By the time maildrop sees the message and begins filtering the
server has long since accepted the message and either closed the SMTP
connection or moved on to other messages.
Thank you.
I had been under the impression that fetchmail did not accept or reject the
messag until it had gotten a zero code either from the local smtp listener or
in the absence of a local smtp listener (as in my system) a return code from
an MDA such as maildrop and that it was therefor able to either purge or
otherwise deal with the message depending on the return code.
So as an alternative question:
Is there a way for maildrop to leave a trail in a log file when it uses
"exit" to blackhole a message?
Clive