On Wed, 28 Jan 2004, David F. Skoll wrote: > On Wed, 28 Jan 2004, Cormack, Ken wrote: > > > It seems that RFC brain-dead mailers are out there, that interpret a > > tempfail as if it were a 5.x.x permanent failure, and the failure is being > > handed back to the sending user's MUA. > > No, what's going on is that the brain-dead senders receive 4xx for all their > RCPT commands. They then issue a DATA command (in spite of the fact that > they MUST not issue DATA unless at least one RCPT succeeded) and Sendmail > correctly responds with a 5xx code. > > I believe Novell Groupwise has this bug. Old SLMail servers did too.
I think there might be more to this than bugs in old MTAs. When I first implemented greylisting a couple of weeks ago, which I did via code in filter_begin (after the DATA phase), I received the following message a few days later from the author of a wine newsletter to which I subscribe. I'm resending this newsletter because it bounced back from your server yesterday morning. Your server may have been down temporarily or your ISP or IT department may have SPAM guard software that's blocking the e-mails - in that case, you may want to e-mail them to ask them not to block it. My newsletter does not come from this e-mail address, but rather from either @postsnet.com or @elecmail.com. The first part of the address changes with each newsletter, so its just these last two parts that you'll want to add to your approved list in your spam guard. Also you may want to ask your ISP or IT department to white-list or not block the flowing IPs from which it does come (these are new): blah blah blah. I checked the mail logs and sure enough elecmail/postnet had attempted to deliver the newsletter and got tempfail'ed a couple of times in rapid succession and after that they never came back to deliver the message. Normally, I wouldn't have cared but I knew that our communications department had recently started using elecmail/postnet to deliver one of their newsletters and when I checked the logs I discovered that one of their mass mailings had also encountered a couple of tempfails and after that they aborted the run, or so it would seem since there were no further attempts in the next 24 hours. The point is that I think its likely that some commercial bulk mailing services (for whom, like spammers, time is money) will treat a 4.x.x like a 5.x.x regardless of when its received. The wine newsletter auther also sent me the name and address of a contact person at postnet/elecmail and I'll write to that person and see if I can get confirmation about my theory. In the meantime, I've been forced to expliticly whitelist the IP addresses used by elecmail/postnet. > > > A. "fought the good fight to prove you are not sending a 5.x.x series status > > code"... and won > > Yes. > > > B. Found something in your milter code or sendmail.cf that IS in fact, > > sending a 5.x.x when a triplet is greylisted > > See above. > > > C. had experience with any such brain-dead MTAs that misinterperet a 4.x.x > > code > > Yes. > > > D. Found a fix, short of whitelisting the problematic hosts > > Yes. With CanIt/CanIt-PRO, we can optionally delay greylisting until > the end of the DATA phase. This wastes bandwidth, but does give most > of the benefits of greylisting without triggering problems on buggy > servers. > > Regards, > > David. > _______________________________________________ > Visit http://www.mimedefang.org and http://www.canit.ca > MIMEDefang mailing list > [EMAIL PROTECTED] > http://lists.roaringpenguin.com/mailman/listinfo/mimedefang > _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang