Re^2: MIME::Lite and Multipart

Replies are listed 'Best First'.
Re^3: MIME::Lite and Multipart by jakobi (Pilgrim) on Sep 29, 2009 at 21:49 UTC
I still don't understand why the "Type" can't be added by itself. Just a note before forwarding you to perldoc, the module source code and zwon for further study: you correctly wrote in the opener: `$message->replace(Type=>'multipart/mixed');`, and this indeed works and changes the mail structure you set with the Type=>... assignment during ->new/->build. Without an explicite Type, Dumper shows a non-MIME text/plain message. Adding mime parts seems to turn the original body (that you never defined in the opener or Re^4) into our undefined problem mime part, while also turning the Type to multipart/mixed. If my assumption is correct, just setting Data=>"" (and never setting a Type at all) before adding attachments should also avoid the undef bugs.	[reply] [d/l]
Re^4: MIME::Lite and Multipart by zwon (Abbot) on Sep 29, 2009 at 22:28 UTC
you correctly wrote in the opener: `$message->replace(Type=>'multipart/mixed');`, and this indeed works No, that's not correct! It creates multipart/mixed with three parts, and it should be multipart/mixed with two parts one of which multipart/alternative and other is attachment.	[reply] [d/l]
Re^5: MIME::Lite and Multipart by jakobi (Pilgrim) on Sep 29, 2009 at 23:01 UTC
Hmm. Checked with dumper. The (fixed) opener code indeed switches to a 3 part multipart/alternative type, which can be successfully mailed, and mutt by default displays the text part of the 2 'inline' parts, and shows all parts with v. Given the implied structure by the code you're right that a hierarchic MIME structure is probably intended by Analog (attaching $alternatives as a (implicit disposition inline?) MIME part to an outer MIME $message as per your skeleton, zwon). And it is indeed preferrable to merely relying on the inline disposition of the working (sensu code sending email instead of aborting) flattened structure produced Analog's initial code scrap. Assuming that modern-day apps should be capable of parsing more than the most trivial of MIMEs (insert some sarcasm of your choice about mailer software quality). Darn it, I really depend on the missing one or two lines of comments, when comparing 2 more or less working code scraps :/. Eyeing the detail makes me register the more elegant code, but it also makes me consider elegance/simplicity to be just a currently irrelevant attribute for the task at hand. sigh, g'night, Peter	[reply]
Re^3: MIME::Lite and Multipart by zwon (Abbot) on Sep 29, 2009 at 22:43 UTC
Yes, you should know if there's attachment, because if there's no attachment you should create only one MIME::Lite object (multipart/alternative message) and there's no need to create `$message` at all.	[reply] [d/l]
Re^4: MIME::Lite and Multipart by Analog (Novice) on Sep 29, 2009 at 23:29 UTC
I understand and thank you guys for the help - I don't know if I agree though, IMO I don't think its right to need to create 2 separate :Lite objects, because if there is no attachment then I need to add the "To", "From", "Subject" keys to that "$alternative" object. I'm not going to complain though, MIME:Lite is a excellent module and I'm lucky it exists.	[reply]
Re^5: MIME::Lite and Multipart by jakobi (Pilgrim) on Sep 30, 2009 at 00:08 UTC
shouldn't you only add To:, Subject:,... to the outermost ::Lite object :)? You insert the alternative ::Lite object into the outer ::Lite object just to get the MIME hierarchy. To:, ... is only used for the mail header, and that only makes sense with the outer ::Lite object finally being mailed (i.e. $message). So you better agree with zwon :) For more info on the mail format and smtp: Check out the original rfc822 and maybe its updates and MIME extension updates for more on the actual email format. Or look at an mbox file on a unix box. As you have an smtp service active, try talking to it with telnet localhost 25 and smtp/esmtp commands (unless the mailer's secured/paranoid even against localhost; maybe strace/truss the mailer process)	[reply]