views:

141

answers:

1

Update: A 4.x.x vs a 5.x.x became the least of my worries when I discovered that not all mail servers return errors according to the "standard". I'm opting to handle all types of returned mail as failures now but I'm leaving this question here in case it gets an answer and helps someone else.

I've been tasked with writing a program to read a POP3 account and differentiate between mail returned as a permanent failure (5.x.x delivery status) and a persistent transient failure (4.x.x delivery status), doing a retry for the 4.x.x DSNs and flagging the email as bad for the 5.x.x DSNs. It's easy enough to hand-edit a DSNs body to change a 5.x.x to a 4.x.x but management would prefer that a "real" 4.x.x be returned. I'm having a lot of trouble doing so.

Test environment is a Windows 2003 Server running MS's SMTP and POP3. I've already tried exceeding the quota on the target email address (5.x.x) and locking the account (2.x.x and they can't get the email).

This is for end-of-lease notices, in case anyone is interested, which is why we're interested in flagging the emails as bad or retrying it the failure wasn't a permanent one.

A: 

Generating a transient failure isn't that hard. A few come to mind:

  • Some sort of local alias expansion failure (this may be more of a Unix thing)
  • DNS lookup timeout (change your nameserver to something silly, or set up a subdomain pointing to a non-existent nameserver)
  • Run your mailserver out of disk space
derobert
I've tried running the mailbox out of disk space and writing protecting; both of those resulted in a 5.x.x failure which leads me to believe running the mailserver out of disk space would do the same. The others might work.
Otis