bjf2000

OK, I didn't understand what was meant by "alternate text" so didn't appreciate that's what was intended with -alttextf. I never would have imagined that's what it was for though, since I would have thought that was more a client-only function, but it makes sense. Likewise, I was leaning the wrong way on -attachi, despite it having the word "attachment" in the name, because for me the word "inline" meant everything and surely referred to the body of the message. But the real horror comes when your...

OK, I didn't understand what was meant by "alternate text" so didn't appreciate that's what was intended with -alttextf. I never would have imagined that's what it was for though, since I would have thought that was more a client-only decision, but it makes sense. Likewise, I was leaning the wrong way on -attachi, despite it having the word "attachment" in the name, because for me the word "inline" meant everything and surely referred to the body of the message. But the real horror comes when your...

Hi. I love Blat and have used it for quite a while, currently v3.2.19 on Windows. The question concerns sending a text file inline. For reasons that I can't fathom, -attachi always sends it as an attachment (tested to two different recipients on different services). So, I found -alttextf, which does send inline, but inserts line breaks into some of the lines, disrupting readability. I thought -raw might solve that, but it has no effect in this instance. Any suggestions? Thanks.

Not sure why that is, since it works here without having changed any security settings (i.e. a clean 1803). I'm guessing you're not running with default security settings, maybe having enabled some of the enhanced protections, where this kind of error would be semi-expected?