gwlester I'm attempting to write a little SMTPD that takes the list of recipients and collapses it down to a unique set (the generating program is not too bright and puts in multiple copies of names and the real SMTPD therefore send multiple copies of the message to each person). The problem is that the message arrives, but without a body or subject. here is the offending code fragment: proc processMail {sender recipients data} { global mailForwardingHost global mailForwardingPort ## ## Create unique list of senders ## ::log::log debug [::msgcat::mc process.original $recipients] array set temp {} foreach recipient $recipients { set temp($recipient) 1 } set recipients [array names temp] ::log::log debug [::msgcat::mc process.resultant $recipients] ## ## Send the mail ## ::log::log debug [::msgcat::mc process.sending $data] set token [mime::initialize -string $data] set results [smtp::sendmessage $token \ -servers $mailForwardingHost \ -ports $mailForwardingPort \ -queue 0 \ -atleastone 1 \ -originator $sender \ -recipients $recipients \ ] mime::finalize $token -subordinates all ## ## Return to caller ## return } lvirden gerald, could you just use lsort -uniq to sort the list leaving only uniq members to skip your loop on array? Irrelevant to the problem... aku Shouldn't a bright smtpd do such collapsing on its own ? gwlester Larry, ahhh yea Andreas, yes -- but this is not a bright one! dan_kuchler So does that answer your question Gerald? You just are going to do a lsort -unique on the $recipients before you call smtp::sendmessage? tclguy exits, stage left! gwlester No, larry just gave me a short cut. The problem is the body and subject are blank when the get to the end destination. But they arent blank in the $data varaible. I guess the real problem is something is wrong with my mimie::initialize, but I have not a clue as to what. aku Is data a message containing headers and body ? lvirden could you show us a sample data value? gwlester Here is an example: {Received: from aspentech.com [127.0.0.1] by LESTERG-ATNO (1.0) id jBvcWBdMFC7G; Mon, 18 Mar 2002 13:18:37 +0600} {Message-ID: <3C963D8D.9E0803A5@aspentech.com>} {Date: Mon, 18 Mar 2002 13:18:37 -0600} {From: "Gerald W. Lester" } {X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)} {X-Accept-Language: en} {MIME-Version: 1.0} {To: gerald.lester@aspentech.com} {Subject: Test Subject} {Content-Type: text/plain; charset=us-ascii} {Content-Transfer-Encoding: 7bit} {} {Test Body} {} {- 40 -} {} {} aku ... Look for the option -canonical. Also note that the original documentation written by Marshall is available (README.* in the module). It is not installed as it is neither manpage nor doctools gwlester Minus the line breaks and the indents. That was a cut from a TkConsole window aku ... but XML with output to HTML and plain text. gwlester Sorry Andrea, did not follow that last comment gwlester BTW, tried -canonical text/plain. It sent a mail message with a base63 encoded attachment. aku I just wanted to note that the manpages I wrote are not the only documentation available, but that the original documentation is there too. aku Look for tcllib/modules/mime/README.* aku ... You are right, -canonical is the wrong answer. It prevents parsing of the string gwlester Looked at the README.txt. Except for the fact that he uses a file and I have a string, it looks the same to me. I know it has to be something stupid I'm doing, but I just can't see it. aku ... The original documentation contains examples aku ... but not for -string dan_kuchler I guess I usually set those headers using the '-header' flag to smtp::sendmessage aku Wait, is the example data truly a list ? Or is that an artifact of copying it from the console ? * clock At the tone, the time is 12:00 on Monday 18 Mar 2002 gwlester Looks like it is a list, but let me check... dan_kuchler smtp::sendmessage $token -servers $smtpServer -header [list To "foo@bar.baz"] -header [list Subject "Here is the subject] dan_kuchler I specify the To, From, and Subject that way, right on the smtp::sendmessge command, not as part of the $data in mime::initializa dan_kuchler I only create the body of the message as a mime part dan_kuchler set token [mime::initialize -canonical "text/plain" \ -string "$message"] gwlester Yep, it is a list. Going to try join it back to a string... aku Yep, mime handles data in RFC (2)822 format, but not lists. gwlester Bingo!! Joining it to a string with new lines makes everything happy. of course if I would have read the SMTPD docs a little closer, it even says: "The procedure is called with the sender, a list of recipients and the text of the mail as a list of lines." Sorry to waste ya'lls time (I knew I was doing something stupid)! Thanks! aku Hm, "the text of the mail as a list of lines. " is ambigous. aku Ah no, not ambigous, but smtpd and mime have different interfaces ... Gah. gwlester I'm not sure why it is being returned as a list. A string or a mime token seems to make a lot more sense. de exits, stage left! aku Ask Pat, he did smtpd IIRC aku Maybe it was code he already had and just moved it into tcllib gwlester Sounds likely, oh well to late now. aku Hm, I am currently doing a pop3 server based on my code in pool. One of the things I have is a storage callback which is used by the server to ask a storage system for the message contents requested by the user. I need headers and (partial) body ... Maybe I should use a mime token here too to get the information. I will think about this. Right now I ask for the headers as string and then a channel to read the body from. aku Maybe all frontend / backend communication in mail modules should be via mime-token. Espacially if we can concentrate things like dot-stuffing in the mime module. aku Right now I do this in the pop3 server. gwlester Mime seems to do a lot of the work for you. I think it would be the way to go. Also that way it just does the "right" thing with "binaries". Yes, I think that it the way to go/ aku No, not too late now IMHO. Next major version of the modules should consolidate and streamline such things aku Ok, I will add several FR's to tcllib with regard to this.