#41 issue with attachment
Hi,
I've used blat for years and it has proven to work perfectly until I try to attach files using 'attach' or 'attacht'.
Environment
- Windows Server 2008 R2 Standard, SP1, 64 bit
- Blat 3.2.3
Blat is triggered with a simple batch script.
My issue is that files are sent/received perfectly as inline (body) msgs but not as attachments.
This batch script works flawlessly without issues.
:: Batch script to send e-mails with blat.exe :: %0 includes the script itself as an attachment :: in the e-mail blat.exe "%0" -to to@myemail.com -f from@myemail.com -s "test" -server mymailserver -SuperDebugT -log blat.log ::end of script
However, the below batch script, with the 'attach' flag, does not work. I've also tried 'attacht' with no success. The length of the file name of the file to be attached fails even if it only contains one character, such as 'a.bat' or 'a.txt'.
:: Batch script to send e-mails with blat.exe :: %0 includes the script itself as an attachment :: in the e-mail blat.exe -attach "%0" -to to@myemail.com -f from@myemail.com -s "test" -server mymailserver -SuperDebugT -log blat.log ::end of script
The failed attempt renders the following log file and the script hangs. I always have to kill it with ctrl+c.
Log file
Checking option -log Blat v3.2.3 (build : Oct 19 2014 15:34:27) 32-bit Windows, Full, Unicode Checking option -attacht Checking option -to Checking option -f Checking option -s Checking option -server
I can't solve the issue with the attach(t) flag that does not render any e-mails.
I've contacted our sysadmin to find out if our mail server blocks attachments but that seem not to be the case.
Any input to help me out is appreciated!
The script does not tell Blat what to send as the message body, so Blat is waiting for keyboard input to create the message. Ctrl-C would cancel the program, while Ctrl-Z would tell Blat that you're finished typing and to then send an email. I would suggest that you give Blat a text file to send as the message body, or use the -body option with some text string.
The first script tells Blat to send the batch file itself as the message body. In the second script, you inserted -attach before the first argument (message body file name), leaving Blat with no message body to send.
Chip
My issue is similar. Blat 3.2.6 (32-bit) under Win2008 (64-bit) was garbling a MyDefrag.log file when used as the first parameter, so I wanted to use -attachi. My email client is Outlook 2013.
-attachi MyDefrag.log with manual Ctrl-Z works and the attachment is inline and not garbled.
-attachi with -body "test" worked without interaction, but then the attachment wasn't inline, though at least not garbled.
Couldn't figure out how to get both the inline file and not require manual interaction.
Mark
Let's start from the original poster's script:
:: Batch script to send e-mails with blat.exe
:: %0 includes the script itself as an attachment
:: in the e-mail
blat.exe -attach "%0" -to to@myemail.com -f from@myemail.com -s "test" -server mymailserver -SuperDebugT -log blat.log
::end of script
I modified the above blat.exe line to read
F:\BLAT\BLAT326\X64\RELEASE\blat.exe -attachi "%0" -p smtp4dev -to myself -s "test" -SuperDebugT -log blat.log -body "Check inline"
Please note that I used the -body option, and the -attachi option. When I open the resulting .eml file using Notepad, I get the following message where the attached "%0" was code for inline. This also rendered properly in Windows Live Mail on my Windows 7 system. If this is not rendering properly for you with Outlook 2013, is there a security setting that is interfering?
Date: Mon, 12 Oct 2015 20:08:22 -0600
From: Chip chip.programmer@att.net
To: Chip chip.programmer@att.net
X-Mailer: Blat v3.2.6, a Win64 (AMD64) SMTP/NNTP mailer http://www.blat.net
Message-ID: 01d1055c$Blat.v3.2.6$09aa9f50$10dc2d0f@127.0.0.1
Subject: test
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_BlatBoundary-13EC6mOm2eRFLEzAJGDsW"
This is a multi-part message in MIME format.
--=_BlatBoundary-13EC6mOm2eRFLEzAJGDsW
Content-Description: Mail message body
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain;
charset="ISO-8859-1"
Check inline
--=_BlatBoundary-13EC6mOm2eRFLEzAJGDsW
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7BIT
Content-Disposition: INLINE
Content-Description: "b.bat"
:: Batch script to send e-mails with blat.exe
:: %0 includes the script itself as an attachment
:: in the e-mail
F:\BLAT\BLAT326\X64\RELEASE\blat.exe -attachi "%0" -p smtp4dev -to myself -s "test" -SuperDebugT -log blat.log -body "Check inline"
::end of script
--=_BlatBoundary-13EC6mOm2eRFLEzAJGDsW--
It just seemed odd to me that -attachi behaved differently when I did a manual Ctrl-Z vs. when I used the -body parameter. In the first case, it appeared as the body of the email (which is what I wanted); in the second, it appeared as a text attachment. I understand that Outlook may shunt inline files to attachments but why doesn't it do it in the first case?
You're right, that was strange. I added a quick check into the code that if a user keys in Ctrl-Z without anything preceding it, then I add a carriage return / line feed as the message body. This then permits the rest of the code to add attachments as intended. This change is in version 3.2.9 that I built this morning.
The other issue of garbling your text file has also been fixed as of last night. I tested my changed with plain text files as well as Unicode text files with and without a byte order marker (BOM). I want to run further tests over the next few days to ensure I have not caused problems. The garbling of your message file was brought about when I attempted to add support for Unicode files that do not have a BOM.
If you want to preview this version, please drop me a note to chip.programmer@att.net.
Thanks for your prompt responses. Re. issue #44, downgrading solved our immediate need so take your time with testing. Just wanted to bring it to your attention.