[exim] "no immediate delivery" vs. queuing

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Yves Goergen
Data:  
Para: exim
Asunto: [exim] "no immediate delivery" vs. queuing
Hi,

Recently somebody misused one of the accounts on my mail server to send
out large amounts of spam. Reading the logs, it came all from a single
IP address, in a single SMTP connection.

I found the following log line:

no immediate delivery: more than 10 messages received in one connection

Do I understand it correctly that Exim decided to no longer try to
deliver e-mails on the same originating SMTP connection and report any
failures immediately, but instead blindly accept all incoming e-mails
and report each failure with a "Mail delivery failed" message in the
poor user's inbox?

That would be the exact opposite of what is recommended and good
behaviour. It leads to massive amounts of delivery error messages AFTER
the messages had been accepted for delivery. My idea was actually to not
take responsibility for any incoming message unless it is sure that it
can be delivered - which can only be known when the message has been
delivered. I don't want to sit on a queue of garbage and let the MTA
throw around error messages to who is almost always the wrong recipient.

The workaround seems to be to set the following configuration somewhere:

smtp_accept_queue_per_connection <number>

Where number is the maximum number of messages per connection to do
whatever with. What implications does it have? Can I set it to
unlimited? Why is that default value of 10 even there if it has such bad
effects?

The queue had over 300,000 files when I had to apply some black magic to
delete it completely. It was almost impossible to handle at all with
Linux means. The user's inbox had over 20,000 error messages, constantly
increasing for hours. No MUA was able to handle that. I don't want to
face that situation ever again even if an account is misused.

--
Yves Goergen
http://unclassified.de
http://dev.unclassified.de