Finding SMTP server names 3

[Glasgow]

I have an application that sends emails. It scans the registry for Outlook Express, Outlook 97 and Outlook 2000 registry keys to find names of SMTP servers used by those applications. The user is then invited to select a server from that list.

Does anyone know where in the registry (or elsewhere) I can get hold of the equivalent information for Outlook 2003 and Outlook 2007? It does not seem to be the same as Outlook 2000 (HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\OMI Account Manager\Accounts).

 

[HarleyQuinn]

I have no idea about 2007 (sorry, don't use it) but I'm thinking for 2002 (and probably 2003) it's in

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows
Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\

Hope this helps

HarleyQuinn
---------------------------------
Carter, hand me my thinking grenades!

You can hang outside in the sun all day tossing a ball around, or you can sit at your computer and do something that matters. - Eric Cartman

Get the most out of Tek-Tips, read FAQ222-2244: How to get the best answers before posting.

http

 

[Glasgow]

Thanks. Indeed that does seem to be the likely spot although the contents appear somewhat cryptic and I'm having problems retrieving them. I will report back.

They seemed to be named and stored in such a fashion that it would appear that Microsoft are not particularly keen on this data being accessed!

 

[dilettante]

I'd think Microsoft has been feeling pressure to help make spamjacking of users' email accounts harder.

For that matter many Windows users rely on a Web-based email client, and have no server parameters to sniff for anyway. On top of that Windows Mail changed the landscape in Vista, and in Win7 Microsoft provides no email client at all in order to escape criticism.

You might want to re-engineer to avoid piggybacking on users' email if possible. Depending on your purpose you might want to eschew using SMTP mail at all. You might move to something like WebDAV if you're trying to do crash reporting or something in your application. It is more firewall-friendly than FTP and can support HTTPS if security is important. WebDAV client support is integral to Windows since at least MDAC 2.5 if not 2.1.

 

[Glasgow]

HarleyQuinn: reporting back as promised. I've got it working, thanks. I was being thrown by fact that the SMTP Server field is stored as binary rather than character data. Every alternate byte would appear to be null so all I'm doing is eliminating these with a Replace function. I Hope that's reasonably safe?!

dilettante: Thanks for the input. I may have to rethink the approach in future. It's arguably unnecessary and creeping into the realms of a "hammer to crack a nut" scenario. I didn't know that about Windows 7. If only the goalposts didn't move quite so fast!

 

[dilettante]

The downside of most alternatives to SMTP mail is that you need a server somewhere to forward your material to. Well, that and the problem that your whole point might be to get email to arbitrary recipients.

The FTP, etc. approach only works for reporting back to a central point really.

If the purpose of your program comes down to emailing in the first place it might be simpler just to require that the user configure a server and account. This isn't so practical for mass market software though.

 

[Glasgow]

The application uses VbSendMail to send email out to selected recipients in a SQL database with the option to copy to a designated 'central' email address - which essentially allows users to verify and accumulate email copies using their own email client.

The idea of scanning the servers is just to make life easier and to allow users to select a server from a list (typically a list of one in practice). They have the option to override the name of the server once it has been pulled into the database and they can specify authentication in an ini file but maybe I just need to haul everything into the database and remove the 'helpful list' as it could become more trouble than it's worth i.e. they specify everything from scratch as I believe you are suggesting.

 

[eVAPor8]

HarleyQuinn: reporting back as promised. I've got it working, thanks. I was being thrown by fact that the SMTP Server field is stored as binary rather than character data. Every alternate byte would appear to be null so all I'm doing is eliminating these with a Replace function. I Hope that's reasonably safe?!

(If I'm guessing correctly)... No it's NOT safe! Far from it in fact!

Those alternate [00] are there because the data is stored in unicode whick is a double-byte format, and you should convert the unicode to chars before relying on it. VB usually handles this automatically for you, but I'm guessing you're using API's to access the Registry and it's not happening.

Can you post your "read key" code and Declarations so we can see what's happening?

Also, check out the string conversion function:

StrConv(ByteArray, vbUnicode)

You'll probably be able to simple StrConv the retuen value from the RegRead return value and a human-sensible in a single line (or even in the Read call itself)

 

[strongm]

>unicode whick is a double-byte format

A pedant writes: not really. UTF-16, which is the native internal representation of text in Windows (W2K and later) is a variable-length character encoding for Unicode characters consisting of either 1 or 2 16-bit words (i.e 2 byte or 4 byte). The older UCS-2, which is what is used by VB, can be considered a subset of UTF-16, and is indeed a double-byte format - but is limited to a very substantial subset (about 6% at best) of the full Unicode codespace.

A bigger pedant writes: and really we should be talking about UTF-16LE and UCS-2LE

 

[Glasgow]

Thanks eVAPor8. I thought it may be unicode but I did not know how to convert. Funny how you can become aware of "new" functions after so many years - I had never stumbled across StrConv. This code does the trick:

      Server = StrConv(Server, vbFromUnicode)