Quick recap of the week so far.
Spent the day loading images off the camera and selecting which ones to post out of 200+ photos taken during my recent road trip to the Kennedy Space Center.
Spent the day dealing with email issues, and writing the monstrous posts for Saturday.
I was supposed to get with Smirk to move computer equipment and install a replacement core router, but he got swamped and rescheduled for Wednesday.
Spent the day dealing with email issues, and dreading the write-up for Sunday.
Also headed into the Data Center to help Smirk move a bunch of equipment and replace our core router with something better. Things go downhill, and we decide to call it a day and regroup on Thursday.
Spent the day dealing with email issues, and headed back into the Data Center to finish up what we started yesterday. Got into the Data Center around 6:00 pm. We start moving equipment and hope that we didn't miss anything.
I left the Data Center around 1:30 am, after having to diagnose a customer's machine that isn't responding on the network. I tracked it down to a possible bad port on the new (new!) replacement router (which is why it took so long to track down—didn't expect a bad port).
Smirk warned me that he might call me in the morning if there are any issues, but hopefully, there aren't any.
Got a call from Smirk at 8:30 am. Turns out to be a minor glitch that is easy to fix. I contemplate going back to bed.
But before I can contemplate too long, Smirk calls back, with yet another email issue (it's bascially the same one that's plagued us all week) and yet another customer is having network issues, possibly due to all the work last night.
The networking issue is mostly resolved when I remove some agressive spanning tree filtering on the port (I thought there was no need to run the spanning tree protocol over that port since it's router-to-router, not switch-to-switch, but due to the actual network topology, it was switch-to-switch—sigh). The remaining issue is the severe lack of OSPF communications between our router and the customer's router.
The email issue is still on-going (more on that later).
Finally buckled down and wrote the write-up for Sunday, and this post.
And here we are …
About that email issue …
Our problems all stem from the greylist daemon I wrote. Or more specifically, the interaction between the greylist daemon and sendmail. Or even more specifically, the greylist daemon and the milter library.
As far as I can tell, the problem is: customer uses
Lookout Outlook or Lookout, Exploit! Outlook Express, configured to use SMTP AUTH. Sendmail hands the authentication off to some other process, which okays it, then sendmail hands the request off to the greylist daemon, which, since it's coming from a foreign address, of course greylists it, and the customer gets an error message from Lookout Outlook or Lookout, Exploit! Outlook Express that says, “Try again later!”
And then we (or our resellers) get a call.
What I would like is for sendmail to skip the greylist daemon if SMTP AUTH is being used, but I'm not sure how to apply the clue-by-four to sendmail.
That's separate from the issue that spammers seem to be clueing in to greylisting and are finding ways around it …