From: David Kerber on
In article <Xns9D677AB0EC727taustingmail(a)69.16.186.7>,
taustinca(a)gmail.com says...
>
> Am I the only one using Ostrosoft's SMTP package? Works very well
> for me.

Me, too. Been using it for years.

D
From: Dee Earley on
On 28/04/2010 10:44, Cor Ligthert[MVP] wrote:
> Helmut,
>
> Default behaviour, exe's don't go trhough almost through not any
> mailserver anymore.

Mailservers do not change the mail.
They MAY defer to filters to do this, but I've not seen any mainstream
MTAs that block these by default out of the box.

After all, that is not their job...

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
From: Jeff Johnson on
"Dee Earley" <dee.earley(a)icode.co.uk> wrote in message
news:uH3Acdt5KHA.1932(a)TK2MSFTNGP05.phx.gbl...

>> Default behaviour, exe's don't go trhough almost through not any
>> mailserver anymore.
>
> Mailservers do not change the mail.

Well, you know, other than maybe inserting a Received header....


From: H-Man on
On Tue, 27 Apr 2010 23:39:40 +0200, Helmut Meukel wrote:

>>> For VB6 i used the VBSendmail.dll and in .Net you can just use the builtin
>>> framework classes however they are perfect in a "simple" situation
>>> even on a MS Exchange network it will not work if SMTP is closed on the mail
>>> server ( this is default on Exchange ) , for a fact in the company i
>>> currently work for we have a Linux mail server especially for our .Net apps
>>> as the admins want to keep the "recomended" settings on the Exchange server
>>> .
>>>
>>
>> Hmmm... That's interesting. Not having ever done anything with Exchange
>> admin, I know nothing about setting it up or configuring it. Or what is
>> recommended best practice or not. But, I know on every corporate exchange
>> network I have been on, I have no problems sending emails using the smtp
>> classes in .NET as long as I set the authentication properly...
>>
>
>
> I gave up trying to understand what happens in the heads of IT admins.
> Just yesterday I sent an update of my app to my customer - appended to an
> email. This time I sent it to his private email address, not his company email
> account.
> Last time I had to send it twice, the exe was stripped from my email and after
> hours trying to get it released from the IT he phoned me to send it to his
> private
> email account. There he _could_ download the exe to his company PC!
> Funny how they have secured their company net, isn't it?
>
> Helmut.

Some of the ways I've gotten around this;
1) simply change the extension to something like .ABC. In the body of the
email the recipient is instructed to rename the file back to .EXE.
2) send in a packed format ie. .ZIP or .7z or something like that.
3) password protect the packed file. sometimes this will go through if
their email AV finds a false positive.


--
HK
From: Karl E. Peterson on
H-Man wrote:
> Some of the ways I've gotten around this;
> 1) simply change the extension to something like .ABC. In the body of the
> email the recipient is instructed to rename the file back to .EXE.
> 2) send in a packed format ie. .ZIP or .7z or something like that.
> 3) password protect the packed file. sometimes this will go through if
> their email AV finds a false positive.

Lots of servers look into ZIPs (passworded or not) for EXEs (and other
executable extensions) now, and filter based strictly on that. I've
associated the XIP extension on my machine to operate identically to
ZIP, and this eases that pain for me just a bit as I routinely need to
send/recieve zipped executables. :-)

--
..NET: It's About Trust!
http://vfred.mvps.org