Jim Ramsay <[EMAIL PROTECTED]> writes: > Tim Legant wrote: >> "Jason R. Mastaler" <[EMAIL PROTECTED]> writes: >> >>>Tim Legant <[EMAIL PROTECTED]> writes: >>> >>> >>>>Hmm. A clarification to this, too. This is not just a tmda-cgi / >>>>Pending.py problem. Although John may not be aware of it, this >>>>message is causing output to LOGFILE_DEBUG (or >>>>TMDA_DELIVERY_FAILURE) each time his MTA tries to deliver it. It >>>>cannot be successfully parsed by HeaderParser and so >>>>Util.msg_from_file fails when tmda-filter runs. >>> >>>I didn't realize this. And there is no way to avoid the HeaderParser >>>error? >> No. That's why I made the comment about Parser raising the >> HeaderParseError even when self.strict is False. In all other cases >> Parser will only raise the HeaderParseError exception if self.strict >> is True. Perhaps that is because messages with this particular error >> can't really be parsed -- they completely violate RFC2822 formatting >> rules. > > Are you saying we can't catch the HeaderParser error for some reason > and ignore the message until the pending queue cleans it up, or are > you saying we can't somehow force the message to be parseable?
Anyone reading the queue using Pending.Message can catch the error and ignore the message. My point is just that, on the tmda-filter side, we can't do that because the message isn't in the queue yet and ignoring incoming messages is the moral equivalent of losing them. For a pending queue reader/manipulator, that's *not* the case. tmda-cgi and tmda-pending can ignore all they want. Putting that exception handling into Pending.Message.__init__ is possible but would require a change to the way the Message class is used; that is, after the Message object is constructed, creators would need to call a check_status() method to see if the Message object represents a real message or not. If not, they would have to ignore it and continue with whatever they were doing. This affects code in Pending.Queue as well as tmda-cgi. Effectively, catching the exception provides exactly the same information without adding another method to the Message interface. > Is there an example message? John's is the first one I've ever seen with this problem. I don't have his message, but the traceback clearly shows where and what the error is. You can easily create one by taking any good message and indenting the first header field by a space or tab. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
