"Jason R. Mastaler" <[EMAIL PROTECTED]> invited blackmail by remarking: > Can we be 100% sure that a 550 will always indicate a fatal and > non-retriable error? The description of 550 seems pretty broad: > > (from RFC 2821, section 4.2.2) > > 550 Requested action not taken: mailbox unavailable > (e.g., mailbox not found, no access, or command rejected > for policy reasons)
Well, I can speak to Earthlink, and to a lesser extent also MSN and mail.com: We use 550s to block spammers, open relays, and networks containing dynamically allocated IPs. Thousands of open relays are blocked daily as they are discovered, and almost as many unblocked as they are repaired and report in. You could easily get a 550 at 09:00 and then get good deliveries by 16:00 if you're in a SOHO environment that misinstalls MS Exchange or something. If you generate too many "policy 550s" too quickly, the mail server could also find itself null-routed for a period of time... This is more the exception than the rule for this case, but perhaps something to consider for people running big servers with lots of TMDA users. As for preferred behavior of how to handle 550s, with an eye to spoofed local domains, I think the current behavior is pretty close to how I like it, actually. If someone sends me a message, and I can't get through to that sender immediately, that's a problem. I'm not sure I'd really want to keep trying if that happened. What I think I would prefer is that instead of generating that nasty debug log that it does, that TMDA actually catch that exception, and then log a much less verbose rejection line in LOGFILE_OUTGOING. If there's anything really worth retrying, this will give me a simpler format so that I may "direct the SMTP client to reinitiate the command sequence by direct action at some point in the future". Regards, DV
msg01295/pgp00000.pgp
Description: PGP signature
