(OT) Using 'mailto' with attachments (Windows)
Helmut Giese
I can use mailto to start the user's email client (most often probably
Outlook) and pass it the destination address, subject and body.
Is it possible to specify an attachment as well?
I tried googling for 'mailto' - not a good idea :(
Thanks for any info and best regards
Helmut Giese
Uwe Klein
> Hello out there,
> I can use mailto to start the user's email client (most often probably
> Outlook) and pass it the destination address, subject and body.
> Is it possible to specify an attachment as well?
>
> I tried googling for 'mailto' - not a good idea :(
--> http://www.packetizer.com/rfc/rfc2368
> Thanks for any info and best regards
> Helmut Giese
you could try passing the attachments base64 encoded in the body?
uwe
Gerald W. Lester
Helmut,
Unless you really want the user to interact with the mail you are
generating, you may want to consider using the TclLib smtp and mime packages
-- they handle attachments nicely.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Helmut Giese
<Gerald...@cox.net> wrote:
>Helmut Giese wrote:
>> Hello out there,
>> I can use mailto to start the user's email client (most often probably
>> Outlook) and pass it the destination address, subject and body.
>> Is it possible to specify an attachment as well?
>>
>> I tried googling for 'mailto' - not a good idea :(
>> Thanks for any info and best regards
>
>Helmut,
>
>Unless you really want the user to interact with the mail you are
>generating, you may want to consider using the TclLib smtp and mime packages
>-- they handle attachments nicely.
Hi Gerald,
but the users would have to configure it wrt the mail server -
possibly even wrt authentication. This won't work - otherwise it would
be an interseting alternative.
Best regards
Helmut Giese
Helmut Giese
<uwe_klein_...@t-online.de> wrote:
>Helmut Giese wrote:
>> Hello out there,
>> I can use mailto to start the user's email client (most often probably
>> Outlook) and pass it the destination address, subject and body.
>> Is it possible to specify an attachment as well?
>>
>> I tried googling for 'mailto' - not a good idea :(
>http://www.google.com/search?q=url+mailto%3A+format
>--> http://www.packetizer.com/rfc/rfc2368
Hi Uwe,
thanks for the link. It never mentions attachments - as is the case
with any other documentation I found on the subject, so it seems that
feature is not supported.
Oh well, ...
>you could try passing the attachments base64 encoded in the body?
Don't think so, technically probably yes, but I don't know what the
users say if they see something they don't recognize.
But it's an option - I'll think about it.
Thanks and best regards
Helmut Giese
Ulrich Schöbel
Hi Helmut,
the multipart/mixed assembled by the mime package
is nothing else but a large text block. There is
no distinction to a 'normal' textual body. It's
only the special knowledge - knowing of mime - of
the receiver, what makes the difference.
I'm sure you will succeed if you use the mime package.
Kind regards
Ulrich
Donal K. Fellows
> I can use mailto to start the user's email client (most often probably
> Outlook) and pass it the destination address, subject and body.
> Is it possible to specify an attachment as well?
No, that's a feature that was deliberately omitted from the RFC for
good security reasons (as should the ability to specify nearly every
message header apart from the subject and keywords). It would be broken
by design in a number of ways too, most notably in that URLs are
intended to be fairly short and attachments are really for dealing with
long data!
> I tried googling for 'mailto' - not a good idea :(
Out of curiosity, I googled for 'mailto attachment' and there is
apparently some mail client out there that supports an 'attachment'
pseudo-header that gives the name of the file to attach (getting around
the length problem at a cost of making the URL just as system-specific
as the file: URL type). But that's crazy (what if some malicious person
gives you a mailto url that sends a sensitive file back to them?) and
you should not make use of it. And I bet that many email clients won't
support adding attachments like that. It's just too broken.
Donal.
Ralf Fassel
| the multipart/mixed assembled by the mime package is nothing else
| but a large text block. There is no distinction to a 'normal'
| textual body. It's only the special knowledge - knowing of mime - of
| the receiver, what makes the difference.
The difference is in the 'Content-Type' mail header line. Without the
appropriate 'Content-Type' header line, attachments probably won't
work properly.
I don't know 'mailto', so I can't say whether you can generate
appropriate header lines for multipart Mime mail bodies. If yes, it
should be straight forward to include the separators in the mail body.
R'
Donal K. Fellows
> I don't know 'mailto', so I can't say whether you can generate
> appropriate header lines for multipart Mime mail bodies. If yes, it
> should be straight forward to include the separators in the mail body.
The RFC states specifically that MIME headers shouldn't be specifiable.
Donal.
Helmut Giese
<donal.k...@man.ac.uk> wrote:
>Helmut Giese wrote:
>> I can use mailto to start the user's email client (most often probably
>> Outlook) and pass it the destination address, subject and body.
>> Is it possible to specify an attachment as well?
>
>No, that's a feature that was deliberately omitted from the RFC for
>good security reasons (as should the ability to specify nearly every
>message header apart from the subject and keywords). It would be broken
>by design in a number of ways too, most notably in that URLs are
>intended to be fairly short and attachments are really for dealing with
>long data!
Hi Donal,
yes, that makes sense.
>> I tried googling for 'mailto' - not a good idea :(
>
>Out of curiosity, I googled for 'mailto attachment' and there is
>apparently some mail client out there that supports an 'attachment'
>pseudo-header that gives the name of the file to attach (getting around
>the length problem at a cost of making the URL just as system-specific
>as the file: URL type). But that's crazy (what if some malicious person
>gives you a mailto url that sends a sensitive file back to them?) and
>you should not make use of it. And I bet that many email clients won't
>support adding attachments like that. It's just too broken.
The context is an app which in case of error I wanted to send some
internal state information (think error message and stacktrace) plus a
screenshot of itself - and make this process as easy as possible for
the user.
Well, I think of something else.
Thanks and best regards
Helmut Giese
Donal K. Fellows
> The context is an app which in case of error I wanted to send some
> internal state information (think error message and stacktrace) plus a
> screenshot of itself - and make this process as easy as possible for
> the user.
Maybe instead use HTTP to upload the dumped files? After all, it's a lot
more efficient than SMTP. If you do, make sure you give the user a
chance to say "no, I don't want you to call home" first, though the
dialog should say why it would be good to allow the app to phone home
and should let the user inspect what data will be sent. MS's crash
handler does something like that IIRC.
Donal.
Helmut Giese
Hey, that's a cute idea.
How would I do this? The only thing I know about http is that my
browser uses it to fetch all the various pages I look at over the day.
<sigh>Why do I keep forgetting to post the context even if the topic
can be explained in a very detailed way? Had I done so, your
suggestion would probably have come up yesterday and could have saved
me today's attempts to guide a (presumably clueless) user to send an
email with attachments.</sigh>
Thanks for a cool idea, which is probably loads more efficient in this
particular context.
Best regards
Helmut Giese
Roy Terry
"Helmut Giese" <hgi...@ratiosoft.com> wrote in message
news:44d76ad7...@News.Individual.DE...
As an aside, It is possible (at least sometimes) to discovery the email
accounts
in use on a Windows box. Here is code that I've used successfully in
the past but it's not widely tested across machines. I'd probably also
never use the info for a connection unless the user confirmed it first.
proc ptEmailRegistryCalcSMTPAccounts {} {
# Look in Windows registry and return
# nested list of accounts found and properties
# This thing might return nothing or unreliable info
# expect it to be useless on win98/ME (13Jun03RT)
# if { ! [isWindows]} {return ""}
package require registry
set PRE {HKEY_CURRENT_USER\Software\Microsoft\Internet Account
Manager\Accounts}
set out ""
foreach k [registry keys $PRE {[0-9]*[0-9]}] {
# ptCon SUBKEY $k
set nk $PRE\\$k
set anAccount ""
set hits 0
foreach vname [registry values $nk] {
if { ! [string match SMTP* $vname]} continue
set v [registry get $nk $vname]
# ptCon $vname=$v
# trim pointless SMTP prefix
incr hits
lappend anAccount [regsub {^SMTP\s*} $vname ""] $v
}
if {$hits} { lappend out $anAccount}
}
return $out
}
> Best regards
> Helmut Giese
Helmut Giese
wrote:
Hi Roy,
thanks for this example. But I think I go the way to do my upload via
HTTP - from my context it makes things so much easier from an user
interface POW, although I do need to get it implemented yet :(
Maybe you have some advice for my follow-up thread "In need of a P..l
script? :)
Thanks and best regards
Helmut Giese