"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. On the other hand, Parser *could* be written to try some obvious things, like stripping leading whitespace (in this particular case) and trying to figure out whether the resulting line makes sense as a header; i.e., starts with a valid field name followed by a colon. Whether this kind of special-casing of incorrectly formatted messages is desirable is another question altogether. It starts down the slippery slope of coding work-arounds for every broken format seen "in the wild", which is essentially a never-ending process that results in nasty, complex, bug-prone code. I've been thinking for a while that TMDA should have a fallback mode for messages that simply can't be parsed. Instead of deferring them endlessly until they time out, we should give up if the parse fails and simply deliver them somewhere. That "somewhere" could be the user's default delivery location or to whatever location is defined by DELIVERY_BOGUS_MESSAGE (which defaults to DELIVERY but can be set to anything, even None; it shouldn't default to None). I haven't thought alot about this because it hasn't been a big priority. However, I think eventually we will decide that it is necessary, since there will always be some crappy messages that can't be parsed and there is no guarantee they are spam (although it's pretty darn likely). Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
