Re: Probable bug in handling message/rfc822

Bob Rogers <[email protected]> writes:

>    The _handle_message method in tmda/TMDA/pythonlib/email/generator.py
> starts with the following comment:
>
>          # The payload of a message/rfc822 part should be a multipart sequence
>          # of length 1.  The zeroth element of the list should be the Message
>          # object for the subpart . . .
>
> But I think this is confusing message/* with multipart/digest; I see no
> hint in RFC 2046 [1] that message/rfc822 bodies contain any internal
> structure (other than whatever may be in the message itself, of course).
>
>    And I have a counterexample:  I forwarded a message to myself using
> VM [2], without adding any text in the body, and I got a top-level
> Content-Type of "message/rfc822" with no multipart structure [first
> attachment].  Passing this message through TMDA fails in the following
> way:
>
>     Uncaught Python 2.5.2 Exception (Wed Jan  6 12:33:04 2010):
>     -----------------------------------------------------------
>     Traceback (most recent call last):
>       File "/usr/bin/tmda-filter", line 53, in <module>
> 	execfile(os.path.join(execdir, 'tmda-rfilter'))
>       File "/usr/bin/tmda-rfilter", line 213, in <module>
> 	orig_msgin_as_string = Util.msg_as_string(msgin)
>       File "/usr/lib64/python2.5/site-packages/TMDA/Util.py", line 552, in msg_as_string
> 	g.flatten(msg, unixfrom=unixfrom)
>       File "/usr/lib/python2.5/site-packages/TMDA/pythonlib/email/generator.py", line 84, in flatten
> 	self._write(msg)
>       File "/usr/lib/python2.5/site-packages/TMDA/pythonlib/email/generator.py", line 109, in _write
> 	self._dispatch(msg)
>       File "/usr/lib/python2.5/site-packages/TMDA/pythonlib/email/generator.py", line 135, in _dispatch
> 	meth(msg)
>       File "/usr/lib/python2.5/site-packages/TMDA/pythonlib/email/generator.py", line 266, in _handle_message
> 	g.flatten(msg.get_payload(0), unixfrom=False)
>       File "/usr/lib/python2.5/site-packages/TMDA/pythonlib/email/message.py", line 185, in get_payload
> 	raise TypeError('Expected list, got %s' % type(self._payload))
>     TypeError: Expected list, got <type 'str'>

The thread 

http://thread.gmane.org/gmane.mail.spam.tmda.user/16395

describes how mail delivery through tmda-ofmipd is impeded by this same
problem: a message/rfc822 attachment throws an error in tmda processing
*after* the email has already been accepted by the tmda-ofmipd server.
The message disappears silently, is never delivered, and no error
message is produced by tmda-ofmipd.  I haven't used message/rfc822
attachments for a couple of years because of this problem.

I believe tmda-ofmipd should in any case catch errors in tmda-processing
after accepting emails for delivery and send a bounce back to the email
sender if a problem occurs.

Cheers,
Nils


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
tmda-workers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmda-workers