The background scenario is that I have been experiencing the "now you see it/now you don't" big-consumer-internet mail service spam blocking. This week it is Verizon.net.

Basically, mail to verizon.net addresses failed and bounced for a 24 hour period on the 12th. Service appeared to have been restored on the 13th. Again, yesterday (the 18th), Verizon quit receiving mail again. The log message being shown by sendmail is of the the form:

Jun 19 10:49:00 julie sendmail[16973]: [ID 801593 mail.info] m5JGmxNk016971: to=<customer@verizon.net>, ctladdr=<vancleef@julie.lostwells.net> (101/10), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=121428, relay=relay.verizon.net. [206.46.232.11], dsn=5.0.0, stat=Service unavailable

For the four days June 13-17, mail went verizon.net normally, dsn-2.0.0, stat=Sent

Two Verizon users have contacted me and told me that they had received no mail from our list since the 11th; that they had contacted Verizon support, and had been told that Verizon was not blocking or dumping our list mails. Both users are sufficiently knowledgeable to have looked for shunting to a "spam" or "bulk" file. I wrote a private e-mail to one user giving log details for him to use. That e-mail bounced back sky high, and the bounce message made clear that Verizon has a spam block on my IP. The log message was another dsn=5.0.0 stat=Service unavailable.

I decided to change the bounce processing so that if this "Service unavailable" bouncing continued into a second day, the affected Verizon users would get bounce-trapped, and I'd see the triggering bounce messages. Accordingly I changed:

Bounce score from 3.0 to 2.0 Discard period from 2 to 4 days Number of warnings from 3 to 2 Notification interval left at 7 days

I've just double checked to be sure that the numbers in the window are 2.0, 4, 2, and 7.

This did exactly what I wanted, and I've got about thirty bounce messages showing 5.7.1 security bounces, some of which I've forwarded (via another IP) to affected Verizon users for their use in dealing with the ISP.

However, I've also gotten about fifty other bounce disables on the 2.0 score. Some investigation shows that affected users had accumulated two bounces several months ago, but none since. From what I see in the bounce logs still in my rotation, it appears that the bounce processor did not sense that these bounces were very stale (over 90 days, when I've specified 4), but simply operated on my reducing the score from 3.0 to 2.0. A couple of users have forwarded back the bounce e-mail they received and have noted the "last bounce dates" in March-April.

Mailman version is 2.1.9, local build with Python 2.4.3 on Solaris 9.

Hank