sysadmin/UnderstandingEximRetries written at 23:16:53; Add Comment
Understanding Exim's weird way of doing retries
First, some terminology. A top level address is an address that a
message starts out being sent to; for example, every (accepted)
The MTA we use now takes what I think of as the straightforward two-phase approach to this. Top level addresses are mapped to destinations in a process called 'routing', the MTA tries to deliver to all destinations, and any destinations that had some temporary delivery failure are remembered to be retried later. When the MTA does retries, it looks up all still undelivered destinations and tries to deliver to them again.
(This ignores retry times, bounces, incomplete DNS lookups, and so on.)
The important effect of the two-phase approach is that a given message's destinations never change; they are determined once when it is received and then frozen.
Exim does not operate this way. Instead of remembering undelivered destinations and retrying them directly, it remembers delivered destinations and whether or not a top level address was completely delivered. Then each time exim retries a message, it re-maps any top level address that has not been completely delivered to destinations, throws away any destination that has already been delivered to, and (re)attempts deliveries on any remaining destinations. (If there are no remaining destinations, the top level address is done.)
So a given message's destinations can change during retries. The
consequence of this is that messages being retried will pick up changes
(Exim has a
This approach does let you correct a routing problem on the fly; you
don't need to change a routing rule and then manually change the
destinations of a pile of stalled messages. But it makes it hard to
see what destination is causing messages to stall (and what the error
message is), since undelivered destinations only exist during retries;
(Technically the information can be dug out of the logs with sufficient work.)
(This is one of those entries I write to make sure that I understand the issue myself.)
spam/SpamSummary-2007-09-29 written at 00:12:18; Add Comment
Weekly spam summary on September 29th, 2007
This week, we:
Volume is a bit up from last week. Looking at the numbers I am reminded of how striking the number of different IP addresses is; the average connection source made less than three connections to us, where the average session source made nine connections (and the average mail source probably did even better, since that is an average of about 44 messages per IP).
Apparently the spammers are back to abusing us on Wednesdays.
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 126.96.36.199/26 19977 1096K otcpicknews.com 188.8.131.52/24 17928 1076K onet.pl 184.108.40.206 13567 814K 220.127.116.11/24 11478 551K adelphia.net 18.104.22.168/24 10808 648K centrum.cz 22.214.171.124 9019 422K 126.96.36.199/23 8400 408K cox.net 188.8.131.52 8287 421K 184.108.40.206 8082 388K 220.127.116.11 6257 375K
Volume is significantly up from last week.
(It warms the black cockles of my heart to see that throwing otcpicknews.com's other netblock straight into our kernel filters was absolutely the right thing to do.)
Connection time rejection stats:
83117 total 41427 bad or no reverse DNS 35442 dynamic IP 4001 class bl-cbl 332 class bl-dsbl 291 acceleratebiz.com 261 class bl-pbl 255 class bl-sdul 188 class bl-sbl 125 qsnews.net 86 class bl-njabl 42 officepubs.com 24 verticalresponse.com
Perversely, volume is down here compared to last week. The highest source of SBL rejections this week was SBL58952 with 66 rejections (a recent listing for a spam source), followed by last week's leading contents of SBL53319 with 25 rejections and SBL48694 with 23 rejections. (Better luck next time, you two! Oh wait, what am I saying? Please drop off the Internet.)
Seventeen of the top 30 most rejected IP addresses were rejected
100 times or more this week; the leader is 18.104.22.168 (1,412
rejections), followed by 22.214.171.124 (1,375 rejections) and
126.96.36.199 (301 rejections). Five are currently in the CBL, two are
(Locally, 20 were rejected for bad or missing reverse DNS, 8 for being dynamic IP addresses, one for being in the NJABL, one for being in the DSBL. Two of those have since changed their status and would not be blocked now.)
This week, Hotmail had:
And the final numbers:
Ah. Well. That would explain a certain amount of everything; we seem to
have been forged as a spam origin in a big way, judging by how these
numbers have jumped so dramatically. The leading source of bad
Bad bounces were sent to 1,421 different bad usernames this week, with
the most popular one being
My pick for the most ironic source of bad bounces this week has to be
* * *
Atom feeds are available; see the bottom of most pages.