errors with sending email using mime/smtp package
Peter Campbell
Tcl: 8.4.5
Error:
400: error flushing "sock568": invalid argument
Stack Trace:
error flushing "sock568": invalid argument
while executing
"flush $channel"
(procedure "mime::copymessageaux" line 175)
invoked from within
"mime::copymessageaux $token $channel "
invoked from within
"mime::copymessage $part $channel"
("foreach" body line 3)
invoked from within
"foreach part $state(parts) {
puts $channel "\n--$boundary"
mime::copymessage $part $channel
..."
("default" arm line 2)
invoked from within
"switch -glob -- $state(content) {
message/* {
puts $channel ""
foreach part $state(parts) {
..."
("parts" arm line 7)
invoked from within
"switch -- $state(value) {
file {
set closeP 1
if {[info exists state(root)]} {
# FRINK: nocheck
vari..."
(procedure "mime::copymessageaux" line 75)
invoked from within
"mime::copymessageaux $token $channel "
invoked from within
"::mime::copymessage $part $state(sd) "
invoked from within
"wtextaux $token $part "
invoked from within
"smtp::sendmessage $multiT -servers [list $setup(smtphost)] -header [list
From "$login::company(NAME) <$login::user(EMAIL_ADDRESS)>"] -header [list
T..."
Any ideas?
All other instances of the email process appear to be working fine.
My code looks like this:
package require mime 1.0
package require smtp 1.0
set filename "$invoice_no.csv"
set message "This email contains an electronic invoice attached as
\"$filename\"."
# parse a message
set messageT [mime::initialize -canonical text/plain -string $message]
set dataT [mime::initialize -canonical "text/plain;
name=\"$filename\"" -string $data]
# create a multipart containing both, and a timestamp
set multiT [mime::initialize -canonical multipart/mixed -parts [list
$messageT $dataT]]
smtp::sendmessage $multiT -servers [list $setup(smtphost)] \
-header [list From "$login::company(NAME) <$login::user(EMAIL_ADDRESS)>"]
\
-header [list To $email] \
-header [list Subject "Invoice $invoice_no"]
# clean everything up
mime::finalize $multiT -subordinates all
Pat Thoyts
>I get the following error from a client site as follows:
>
>Tcl: 8.4.5
>
>Error:
>
>400: error flushing "sock568": invalid argument
>
>Stack Trace:
>
>error flushing "sock568": invalid argument
> while executing
>"flush $channel"
> (procedure "mime::copymessageaux" line 175)
> invoked from within
I don't see anything obvious wrong. You can get information about the
SMTP transaction if you add '-debug 1' to the smtp::sendmessage
command. This may well help. Looks to me like the channel got closed
early or something. You dont say which version of smtp you have -- I
tested your code here with 1.3.5 and it was ok. Here is what the smtp
session looks like when successful...
Trying gloucester...
<-- 220 gloucester.localnetwork ESMTP Server (Microsoft Exchange
Internet Mail Service 5.5.2653.13) ready
--> EHLO uknml1037 (wait upto 300 seconds)
<-- 250-gloucester.localnetwork Hello [uknml1037.localnetwork]
<-- 250-XEXCH50
<-- 250-HELP
<-- 250-ETRN
<-- 250-DSN
<-- 250-SIZE 0
<-- 250-AUTH LOGIN
<-- 250 AUTH=LOGIN
--> MAIL FROM:<patrick.thoyts@localnetwork> (wait upto 600 seconds)
<-- 250 OK - mail from <patrick.thoyts@localnetwork>
--> RCPT TO:<patrick.thoyts@localnetwork> (wait upto 3600 seconds)
<-- 250 OK - Recipient <patrick.thoyts@localnetwork>
--> DATA (wait upto 300 seconds)
<-- 354 Send data. End with CRLF.CRLF
--> . (wait upto 120 seconds)
<-- 250 OK
--> QUIT (wait upto 120 seconds)
<-- 221 closing connection
--
Pat Thoyts http://www.zsplat.freeserve.co.uk/resume.html
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Peter Campbell
systems:
THIS ONE WORKS OK:
<-- 220 hermes.acs.co.nz ESMTP Sendmail 8.11.6/8.11.6; Fri, 30 Apr 2004
16:04:49 +1200
--> EHLO pc1 (wait upto 300 seconds)
<-- 250-hermes.acs.co.nz Hello dhcp67.acs.co.nz [192.168.100.67], pleased to
meet you
<-- 250-ENHANCEDSTATUSCODES
<-- 250-8BITMIME
<-- 250-SIZE
<-- 250-DSN
<-- 250-ONEX
<-- 250-ETRN
<-- 250-XUSR
<-- 250 HELP
--> ONEX (wait upto 300 seconds)
<-- 250 2.0.0 Only one transaction
--> MAIL FROM:<p...@acs.co.nz> (wait upto 600 seconds)
<-- 250 2.1.0 <p...@acs.co.nz>... Sender ok
--> RCPT TO:<p...@acs.co.nz> (wait upto 3600 seconds)
<-- 250 2.1.5 <p...@acs.co.nz>... Recipient ok
--> DATA (wait upto 300 seconds)
<-- 354 Enter mail, end with "." on a line by itself
--> . (wait upto 120 seconds)
<-- 250 2.0.0 i3U44nE28110 Message accepted for delivery
--> QUIT (wait upto 120 seconds)
<-- 221 2.0.0 hermes.acs.co.nz closing connection
THIS ONE GETS THE ERROR AS SEEN (BELOW)
<-- 220 mta2-rme.xtra.co.nz ESMTP server ready Fri, 30 Apr 2004 15:51:11
+1200
--> EHLO FACTORING (wait upto 300 seconds)
<-- 250-mta2-rme.xtra.co.nz
<-- 250-HELP
<-- 250-XREMOTEQUEUE
<-- 250-ETRN
<-- 250-PIPELINING
<-- 250-DSN
<-- 250-8BITMIME
<-- 250 SIZE 52428800
--> MAIL FROM:<p...@acs.co.nz> (wait upto 600 seconds)
<-- 250 Sender <p...@acs.co.nz> Ok
--> RCPT TO:<p...@acs.co.nz> (wait upto 3600 seconds)
<-- 250 Recipient <p...@acs.co.nz> Ok
--> DATA (wait upto 300 seconds)
<-- 354 Ok Send data ending with <CRLF>.<CRLF>
--> RSET (wait upto 0 seconds)
--> QUIT (wait upto 0 seconds)
400: error writing "sock284": invalid argument
() 14 %
The end result is the mailserver sends part of the message.
"Pat Thoyts" <c...@mfcyng.serrfreir.pb.hx> wrote in message
news:87isfjg...@binky.home...
Gerald W. Lester
> Here are two transcripts sending a similar message from two different
> systems:
>
> THIS ONE WORKS OK:
> THIS ONE GETS THE ERROR AS SEEN (BELOW)
>
> <-- 220 mta2-rme.xtra.co.nz ESMTP server ready Fri, 30 Apr 2004 15:51:11
> +1200
> --> EHLO FACTORING (wait upto 300 seconds)
> <-- 250-mta2-rme.xtra.co.nz
> <-- 250-HELP
> <-- 250-XREMOTEQUEUE
> <-- 250-ETRN
> <-- 250-PIPELINING
> <-- 250-DSN
> <-- 250-8BITMIME
> <-- 250 SIZE 52428800
> --> MAIL FROM:<p...@acs.co.nz> (wait upto 600 seconds)
> <-- 250 Sender <p...@acs.co.nz> Ok
> --> RCPT TO:<p...@acs.co.nz> (wait upto 3600 seconds)
> <-- 250 Recipient <p...@acs.co.nz> Ok
> --> DATA (wait upto 300 seconds)
> <-- 354 Ok Send data ending with <CRLF>.<CRLF>
> --> RSET (wait upto 0 seconds)
> --> QUIT (wait upto 0 seconds)
> 400: error writing "sock284": invalid argument
> () 14 %
The server is closing the connection on you. Now the question is why. My
guess is it processing the message as you are sending it and "sees"
something it does not like (maybe comparing the extensions on the file name
to the mime type and deciding that a .csv should be something like
application/ms-excel instead of text/plain and therefore you must be
attempt to pass a virus).
You may want to try the -queue option and sees if it later sends you a mail
message indicating what is wrong.
Also you may want to either examine the logs on the server (or ask the
machine's admin to) and see if it is printing out any helpful error messages.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+
Pat Thoyts
[snip]
>--> DATA (wait upto 300 seconds)
><-- 354 Enter mail, end with "." on a line by itself
>--> . (wait upto 120 seconds)
><-- 250 2.0.0 i3U44nE28110 Message accepted for delivery
>--> QUIT (wait upto 120 seconds)
><-- 221 2.0.0 hermes.acs.co.nz closing connection
>--> DATA (wait upto 300 seconds)
><-- 354 Ok Send data ending with <CRLF>.<CRLF>
>--> RSET (wait upto 0 seconds)
>--> QUIT (wait upto 0 seconds)
>400: error writing "sock284": invalid argument
>() 14 %
OK Various characters seem to be missing here but I suspect that to be
a copy error. The main difference is the RSET command. The client is
resetting the connection with that.
It looks like you need to examine the content too. One way might be to
add some output into the smtp.tcl code. Another is to get 'sockspy'
which is a tcl script that can show you the data passing through a
socket. There is a starkit copy at
http://mini.net/sdarchive/sockspy.kit
If you set up as
tclkit sockspy.kit 2525 your.mail.server 25
and then use localhost 25 for the mail server then you can examine the
entire SMTP traffic. You will be able to see where the server gives up
on you with this.
Roy Terry
>
> I get the following error from a client site as follows:
to try disabling the use of trf in smtp.tcl. That's the
only way I've found to send e-mails with mime attachments from
my win 2000 box.
Here's a fragment starting from about
line 959 in smtp.tcl (<Tcl-install>/lib/tklib1.6/mime)
Notice where I unconditionally "set trf 0"
...
proc ::smtp::wtextaux {token part} {
global errorCode errorInfo
# FRINK: nocheck
variable $token
upvar 0 $token state
# Workaround a bug with stacking channels on top of TLS.
# FRINK: nocheck
set trf [set [namespace current]::trf]
if {[info exists state(tls)] && $state(tls)} {
set trf 0
}
set trf 0 ;# 15Mar04RT - get ultranotes working
flush $state(sd)
fileevent $state(sd) readable ""
if {$trf} {
....
Good luck and please report back
whatever solution you may find.
BTW, have you reviewed outstanding bug
reports on smtp/mime? I believe I
have reported a bug related to the
above situation and there are
reports on trf having issues with
whitespace too I believe.
Roy
Peter Campbell
I tested sending an email with no attachment, this worked fine.
I tried sending the email with the attachment, and get the error.
Using our own mailserver and email addresses this works fine.
Transcript of failed sending follows.
I presume it is something specific to the email server, but it is New
Zealand's biggest ISP and so I suspect they aren't doing anything too weird.
% # now email the file
(Desktop) 2 % package require mime 1.0
1.3.3
(Desktop) 3 % package require smtp 1.0
1.3.3
(Desktop) 4 %
(Desktop) 4 % set filename "test.txt"
test.txt
(Desktop) 5 % set message "This email contains an electronic invoice
attached as \"$filename\"."
This email contains an electronic invoice attached as "test.txt".
(Desktop) 6 %
(Desktop) 6 % # parse a message
(Desktop) 7 % set messageT [mime::initialize -canonical text/plain -string
$message]
::mime::1
(Desktop) 8 % set dataT [mime::initialize -canonical "text/plain;
name=\"$filename\"" -file /fbase/new/database.tcl]
::mime::2
(Desktop) 9 %
(Desktop) 9 % # create a multipart containing both, and a timestamp
(Desktop) 10 % set multiT [mime::initialize -canonical
multipart/mixed -parts [list $messageT $dataT]]
::mime::3
(Desktop) 11 %
(Desktop) 11 % smtp::sendmessage $multiT -servers [list
{smtp.xtra.co.nz}] -debug 1 \
> -header [list From "<rach...@becarparts.co.nz>"] \
> -header [list To rach...@becarparts.co.nz] \
> -header [list Subject "Invoice TEST"]
Trying smtp.xtra.co.nz...
<-- 220 mta1-rme.xtra.co.nz ESMTP server ready Mon, 3 May 2004 09:20:28
+1200
--> EHLO pc1 (wait upto 300 seconds)
<-- 250-mta1-rme.xtra.co.nz
<-- 250-HELP
<-- 250-XREMOTEQUEUE
<-- 250-ETRN
<-- 250-PIPELINING
<-- 250-DSN
<-- 250-8BITMIME
<-- 250 SIZE 52428800
--> MAIL FROM:<rach...@becarparts.co.nz> (wait upto 600 seconds)
<-- 250 Sender <rach...@becarparts.co.nz> Ok
--> RCPT TO:<rach...@becarparts.co.nz> (wait upto 3600 seconds)
<-- 250 Recipient <rach...@becarparts.co.nz> Ok
--> DATA (wait upto 300 seconds)
<-- 354 Ok Send data ending with <CRLF>.<CRLF>
--> RSET (wait upto 0 seconds)
--> QUIT (wait upto 0 seconds)
400: error writing "sock132": invalid argument
(Desktop) 12 %
(Desktop) 12 % # clean everything up
(Desktop) 13 % mime::finalize $multiT -subordinates all
(Desktop) 14 %
"Gerald W. Lester" <Gerald...@cox.net> wrote in message
news:8Qlkc.3506$Lm3.3479@lakeread04...
Gerald W. Lester
> I have done some more testing, trying to eliminate the problems.
> I tested sending an email with no attachment, this worked fine.
> I tried sending the email with the attachment, and get the error.
> Using our own mailserver and email addresses this works fine.
>
> Transcript of failed sending follows.
> I presume it is something specific to the email server, but it is New
> Zealand's biggest ISP and so I suspect they aren't doing anything too weird.
I noticed the attachments are not .txt files.
Please rerun the test with attachments, but this time only use files with a
.txt extension and a mime type of text/plain and report the results.
Also, I suggest you send the same log information that you posted here to
the ISP and ask them why they are rejecting the mail. (If it would have
rejected the mail without the attachment I would have guessed it thought
you were attempting a relay.)
Peter Campbell
no relevance so the filename is not being used for anything.
I will send the log details to the ISP and see if they can shed any light on
it.
"Gerald W. Lester" <Gerald...@cox.net> wrote in message
news:1jelc.5086$Lm3.567@lakeread04...
Gerald W. Lester
> The data I am using via (-file) doesn't have a .txt extension but that is of
> no relevance so the filename is not being used for anything.
Peter,
I've seen servers bouncing e-mails because they had a file with a .zip
extension -- regardless of the mime type. These same servers have allowed
through the same file with a .zzz extension -- even if the mime type said
it was a zip file!
Some people are doing stupid things in the name of "protection".
BTW, please post and let us know the answer!
Peter Campbell
more testing.
1. The error is not specific to having attachments, I can replicate without
an attachment.
2. The error seems specific to the entire message being over about 8K.
I tested sending small files (<6K) and these were sent ok so I tried sending
a large message (>8K) without any attachments and this got an error also.
Help! In the meantime I am investigating the mime/smtp source code
further....
Peter Campbell
I posted a message a few days ago and have been trying to solve the problem
I get when sending email to a particular SMTP server.
I have isolated the problem to be related to the size of the message -
nothing to do whether attachments or not.
Here is the transcript of the message (as recorded by sockspy).
14:34:59 connect from 127.0.0.1 localhost 25 1528
14:34:59 connecting to smtp.xtra.co.nz:25
14:35:02 220 web4-rme.xtra.co.nz ESMTP server ready Fri, 7 May 2004 14:34:51
+1200
14:35:02
14:35:02 EHLO localhost
14:35:02
14:35:03 250-web4-rme.xtra.co.nz
14:35:03 250-HELP
14:35:03 250-XREMOTEQUEUE
14:35:03 250-ETRN
14:35:03 250-PIPELINING
14:35:03 250-DSN
14:35:03 250-8BITMIME
14:35:03 250 SIZE 52428800
14:35:03
14:35:03 MAIL FROM:<rach...@becarparts.co.nz>
14:35:03
14:35:03 250 Sender <rach...@becarparts.co.nz> Ok
14:35:03
14:35:03 RCPT TO:<rach...@becarparts.co.nz>
14:35:03
14:35:03 250 Recipient <rach...@becarparts.co.nz> Ok
14:35:03
14:35:03 DATA
14:35:03
14:35:03 354 Ok Send data ending with <CRLF>.<CRLF>
14:35:03
14:35:03 MIME-Version: 1.0
14:35:03 Content-ID: <4293226069.1083897299.67@pc1>
14:35:03 From: <rach...@becarparts.co.nz>
14:35:03 To: rach...@becarparts.co.nz
14:35:03 Subject: Invoice TEST
14:35:03 Date: Fri, 07 May 2004 14:34:59 +1200
14:35:03 Message-ID: <4293226069.1083897299.68@pc1>
14:35:03 Content-Type: multipart/mixed;
14:35:03 boundary="----- =_FJPvtTXYqgFpLgR1pPzd/w=="
14:35:03
14:35:03 ------- =_FJPvtTXYqgFpLgR1pPzd/w==
14:35:03 MIME-Version: 1.0
14:35:03 Content-ID: <4293226069.1083897299.65@pc1>
14:35:03 Content-Type: text/plain
14:35:03
14:35:03 This email contains an electronic invoice.
14:35:03
14:35:03
14:35:03 ------- =_FJPvtTXYqgFpLgR1pPzd/w==
14:35:03 MIME-Version: 1.0
14:35:03 Content-ID: <4293226069.1083897299.66@pc1>
14:35:03 Content-Type: text/plain
14:35:03 Content-Transfer-Encoding: quoted-printable
14:35:03
14:35:03
14:35:03 ############################################
14:35:03 ## (c) Peter Campbell Software 2001-2004, all rights reserved.
##
14:35:03 ## http://www.fastbase.co.nz
=
14:35:03 ##
14:35:03 ############################################
14:35:03 BALANCE_CURRENCY char(3) NULL,
** I have removed about 500 lines of text here that was also sent **
14:35:03 PAYMENT_METHOD char(1) NULL,
14:35:03 SUPPLIER_CODE char(1
14:35:03
14:35:03 .
14:35:03
14:35:03 RSET
14:35:03 QUIT
14:35:03
14:35:03 ----- closed connection -----
14:35:03 waiting for new connection...
As you can see the system has added a blank line, dot, then blank line well
before the end of the file. The message/file I was sending did not stop
where it did - somehow the message has been truncated.
I have now tried this on a couple of SMTP servers and get similar results.
The SMTP does not log anything out of the ordinary, it gets what is sent and
accepts it.
Please help.
Roy Terry
[repost by Roy Terry] ...
Peter Campbell wrote:
>
> I get the following error from a client site as follows:
Roy
>
> Tcl: 8.4.5
>
> Error:
>
> 400: error flushing "sock568": invalid argument
>
> Stack Trace:
>
> error flushing "sock568": invalid argument
> while executing
> "flush $channel"
> (procedure "mime::copymessageaux" line 175)
> invoked from within
> set message "This email contains an electronic invoice attached as
> \"$filename\"."
>
> # parse a message
> set messageT [mime::initialize -canonical text/plain -string $message]
> set dataT [mime::initialize -canonical "text/plain;
> name=\"$filename\"" -string $data]
>
> # create a multipart containing both, and a timestamp
> set multiT [mime::initialize -canonical multipart/mixed -parts [list
> $messageT $dataT]]
>
> smtp::sendmessage $multiT -servers [list $setup(smtphost)] \
> -header [list From "$login::company(NAME) <$login::user(EMAIL_ADDRESS)>"]
> \
> -header [list To $email] \
> -header [list Subject "Invoice $invoice_no"]
>
> # clean everything up
Gerald W. Lester
> I posted a new message but here is that comment also...
>
>
> I posted a message a few days ago and have been trying to solve the problem
> I get when sending email to a particular SMTP server.
> I have isolated the problem to be related to the size of the message -
> nothing to do whether attachments or not.
>
> Here is the transcript of the message (as recorded by sockspy).
> ** I have removed about 500 lines of text here that was also sent **
>
> 14:35:03 PAYMENT_METHOD char(1) NULL,
> 14:35:03 SUPPLIER_CODE char(1
> 14:35:03
> 14:35:03 .
> 14:35:03
> 14:35:03 RSET
> 14:35:03 QUIT
> 14:35:03
> 14:35:03 ----- closed connection -----
> 14:35:03 waiting for new connection...
>
> As you can see the system has added a blank line, dot, then blank line well
> before the end of the file. The message/file I was sending did not stop
> where it did - somehow the message has been truncated.
> I have now tried this on a couple of SMTP servers and get similar results.
> The SMTP does not log anything out of the ordinary, it gets what is sent and
> accepts it.
Peter,
Most SMTP servers put a limit on message size. In the U.S. it tends to be
around 5M. I find it difficult to believe that they are imposing a 5K limit
on you. So....
Can you send the large text file via another mail client?
If so, please send it to me and I'll attempt to send it back directly and
indirectly. Maybe we'll get a clue as to what is going on.
Peter Campbell
Another application is successfully sending email attachments over 1MB.
After reviewing everything that is happening it does appear to be a bug with
the handling of the whitespace/blank lines in messages and/or attachments.
I also got some feedback from the ISP, they made some relevant comments but
nothing pointed me to a solution.
Our own mail server was also getting the same response, but then part way
through testing the mail server started getting the entire messages ok. So
really confusing, I stopped going any further.
Also, I tried "set trf 0", this had an effect, more of the message got
through but it still broke (aborted the message part way through).
"Roy Terry" <royt...@earthlink.net> wrote in message
news:4092672F...@earthlink.net...
Peter Campbell
package, an incompatibility. The transform function of the "trf" package
sends back a command "query/ratio" which the "smtp::wdata" function does not
know - this returns the error.
I included some debugging information in the mime package to delve deeper
into the code and find the original error messages, rather than the message
as reported by the application.
By editing "smtp.tcl" and removing the usage of Trf the sending of the email
works.
ie: remove the trf line at the top, so create our own transform procedure.
smtp.tcl; line 37:
if {[catch {package require Trf 2.0}]} {
# Trf is not available, but we can live without it as long as the
# transform and unstack procs are defined.
# Warning!
# This is a fragile emulation of the more general calling sequence
# that appears to work with this code here.
proc transform {args} {
upvar state mystate
set mystate(size) 1
}
proc unstack {channel} {
# do nothing
return
}
set ::smtp::trf 0
}
The following is the output from my debugging:
(Desktop) 11 % smtp::sendmessage $multiT -servers [list {localhost}] -debug
1 \
> -header [list From "<p...@acs.co.nz>"] \
> -header [list To p...@acs.co.nz] \
> -header [list Subject "Invoice TEST"]
Trying localhost...
<-- 220 hermes.acs.co.nz ESMTP Sendmail 8.11.6/8.11.6; Tue, 11 May 2004
09:39:31 +1200
--> EHLO localhost (wait upto 300 seconds)
<-- 250-hermes.acs.co.nz Hello dhcp67.acs.co.nz [192.168.100.67], pleased to
meet you
<-- 250-ENHANCEDSTATUSCODES
<-- 250-8BITMIME
<-- 250-SIZE
<-- 250-DSN
<-- 250-ONEX
<-- 250-ETRN
<-- 250-XUSR
<-- 250 HELP
--> ONEX (wait upto 300 seconds)
<-- 250 2.0.0 Only one transaction
--> MAIL FROM:<p...@acs.co.nz> (wait upto 600 seconds)
<-- 250 2.1.0 <p...@acs.co.nz>... Sender ok
--> RCPT TO:<p...@acs.co.nz> (wait upto 3600 seconds)
<-- 250 2.1.5 <p...@acs.co.nz>... Recipient ok
--> DATA (wait upto 300 seconds)
<-- 354 Enter mail, end with "." on a line by itself
result =
ecode = NONE
einfo = Unknown command "query/ratio"
while executing
"error "Unknown command \"$command\"""
("default" arm line 2)
invoked from within
"switch -- $command {
create/read
-
create/write
-
clear/write
-
delete/write {
set s..."
(procedure "::smtp::wdata" line 6)
invoked from within
"::smtp::wdata ::smtp::1 query/ratio {}"
I am sure the correct way to solve this problem is to update the
"smtp::wdata" procedure to handle the "query/ratio" command (and any others
that the Trf package provides).
Plus enhance the flow of error messages within the mime/smtp package so the
original error information is not lost.
ps: I am not familiar with filing bug reports on sourceforge, could somebody
take the libity of doing this, thank you.
Peter Campbell
package source:
# fix a problem with the smtp/mime package (tcl 8.4.6, check version when we
know it's fixed)
rename package __package_fb
proc package {what args} {
switch -- $what {
require {
if {[lindex $args 0] == "Trf"} {
error "Incompatible package, not supported as at 11/05/2004; FastBase"
} else {
eval __package_fb {$what} $args
}
}
default { eval __package_fb {$what} $args }
}
}
Pat Thoyts
>ps: I am not familiar with filing bug reports on sourceforge, could somebody
>take the libity of doing this, thank you.
Bug raised -
http://sourceforge.net/tracker/index.php?func=detail&aid=951568&group_id=12883&atid=112883