Finding the user"s ISP"s outgoing mail server?

Hi folks

I'm adding email functionality to a software application. Each user is
known to be "connected to the internet", but they do not necessarily
have an email client on their PC. So I'm planning to add an SMTP
component to the application, to send the email directly to the
outgoing mailserver of the user's ISP.

So it's the old question: how do I identify that mailserver, through
code?

Here's my plan. AFAIK, most (all?) ISPs give their users an email
address. What if I ask the user to enter that email address, and then I
do an MX query on the domain of that address? Eg. the user enters
"me@blah.com", and I do an MX query on "blah.com", and use the result
as the SMTP server address?

AFAICS, this would *have to* return the address of the user's ISP's
*incoming* mail server, since it is the same method that other
mailservers use, to get that information. But I wonder would the same
address would generally work for *outgoing* emails? That is, *if* the
ISP had different mailservers for incoming & outgoing email, could I
expect to send emails via their *incoming* mailserver (the one
identified by my process abve), or would that usually be rejected?

TIA,
TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

>Here's my plan. AFAIK, most (all?) ISPs give their users an email
>address. What if I ask the user to enter that email address, and then I
>do an MX query on the domain of that address? Eg. the user enters
>"me@blah.com", and I do an MX query on "blah.com", and use the result
>as the SMTP server address?

I think that this works only in some but definately not all cases.
Potential problems I see are

a) the incoming server does not HAVE to be the outgoing one.
b) Many ISP's these days requiere the sending clients to authenticate
c) Even if you get the right server, you get it's external IP address
if you resolve it. It very well might be that this server seen from
the PC you are runing at must be addressed differently.

Again, you might get away with this aproach every now and then, but
definately not always. There is IMHO no way to overcome the listed
problems except by asking the user at install time for the propper
information. It also very well might be that I did not identified all
cases where it does not work :-)

HTH

Markus

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-19308-1147342670-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

TC writes:

> Hi folks
>
> I'm adding email functionality to a software application. Each user is
> known to be "connected to the internet", but they do not necessarily
> have an email client on their PC. So I'm planning to add an SMTP
> component to the application, to send the email directly to the
> outgoing mailserver of the user's ISP.
>
> So it's the old question: how do I identify that mailserver, through
> code?

You can't. The name of the user's smarthost is determined entirely by the
user's ISP.

The name of the user's smarthost must be manually configured.

> Here's my plan. AFAIK, most (all?) ISPs give their users an email
> address. What if I ask the user to enter that email address, and then I
> do an MX query on the domain of that address? Eg. the user enters
> "me@blah.com", and I do an MX query on "blah.com", and use the result
> as the SMTP server address?

Wrong.


> TIA,
> TC (MVP MSAccess)

Why doesn't that suprise me?



--=_mimegpg-commodore.email-scan.com-19308-1147342670-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEYw9Ox9p3GYHlUOIRAqJpAJ9FDcAx2FSxjMiC+BYIHM+W0xuBPACf YbDi
11dHZLtZTIcVBm+Cx5iIM4s=
=CSXM
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-19308-1147342670-0001--

Re: Finding the user"s ISP"s outgoing mail server?

Sam wrote:

> > TIA,
> > TC (MVP MSAccess)
>
> Why doesn't that suprise me?

WTF ??

I have more than 30 years of professional software development
experience. I've lead a development team of professional software
designers, analysts & programmers, in a 4.5 *billion* dollar defense
project, developing Oracle/Unix software that required *ten thousand
hours* of development work.

So who the frig are YOU, to laugh at ME? What is YOUR comparative
experience? Please explain your personal software development
experience. Feel free to list the number of multi-thousand hour
development projects that you have undertaken in multi billion dollar
software projects.

I'll try to make it easy for you. Just fill out the blanks below:

1.

2.

3.

4.

5.

I look forward to reading your reply.

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

Hi Markus, thanks for replying.

Markus Zingg wrote:

> Potential problems I see are
>
> a) the incoming server does not HAVE to be the outgoing one.

That's what I thought. So the question is, would incoming servers
typically accept, or reject, *outgoing* emails?


> b) Many ISP's these days requiere the sending clients to authenticate

No problems with that. I plan to support AUTH, and POP before SMTP.


> c) Even if you get the right server, you get it's external IP address
> if you resolve it. It very well might be that this server seen from
> the PC you are runing at must be addressed differently.

Sorry, I'm not sure if I understand that. To "get the right server"
means, to me, that I would somehow get the name (eg. smtp.blah.com), or
IP address (eg. 11.22.33.44), of the correct outgoing mailserver. How
would that name or address need to be "addressed differently" from the
PC? I don't understand what you are getting at there.

TIA,
TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

>That's what I thought. So the question is, would incoming servers
>typically accept, or reject, *outgoing* emails?

They obviousely would reject it so as they can't be abused as a relay.

[snip]
>No problems with that. I plan to support AUTH, and POP before SMTP.

Errr.. and how do you intend to find out the needed login and
password? If you have to ask the user for this information then you
can also ask for the propper mailserver at the same time...

[snip]
>Sorry, I'm not sure if I understand that. To "get the right server"
>means, to me, that I would somehow get the name (eg. smtp.blah.com), or
>IP address (eg. 11.22.33.44), of the correct outgoing mailserver. How
>would that name or address need to be "addressed differently" from the
>PC? I don't understand what you are getting at there.

Imagine a site with their own mailserver siting in the internal
network or DMZ. Your name resolution of mail.bla.com would return the
external IP of said organisation. It's however NOT said that if you
try to talk to that IP from within the lan of this organisation that
the IP would be propperly routed.

HTH

Markus

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:
> Hi folks
>
> I'm adding email functionality to a software application. Each user is
> known to be "connected to the internet", but they do not necessarily
> have an email client on their PC. So I'm planning to add an SMTP
> component to the application, to send the email directly to the
> outgoing mailserver of the user's ISP.
>
> So it's the old question: how do I identify that mailserver, through
> code?
>
[deleted]
>
> TIA,
> TC (MVP MSAccess)

Taking a totally different approach:

You didn't mention the intended platform(s) (Why bother with such
'details'? :-(), but seeing your sig, I assume it might be (MS-)Windows.
If so, you might want to consider your question to be a *Windows*
question and post it to an/the appropriate groups.

Why? Because viri/viruses are known to get this kind of information
from the Windows configuration (registry?). While this might not work
for *all* possible MUAs (Mail User Agents / 'mailers'), it will probably
work for the more *common* ones, like Outlook (Express) and probably
also the Netscape/Mozilla family.

The authentication issue is indeed a valid one, so perhaps you still,
at least sometimes, have to ask the user for their (email) password(s)

I hope this helps.

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-27240-1147388309-0001
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg

TC writes:

>=20
> Sam wrote:
>=20
>> > TIA,
>> > TC (MVP MSAccess)
>>
>> Why doesn't that suprise me?
>=20
> WTF ??

My thoughts exactly.

> I have more than 30 years of professional software development
> experience.

Which is more the reason why you should know how, and if, one is able to=20
find a mail server.

I venture a guess: you were not able to locate a function of your=20
ActiveVirus/dot-Nyet control that does this, and when that happens you're=20
totally lost, and don't know where to look, right?

> I've lead a development team of professional software
> designers, analysts & programmers, in a 4.5 *billion* dollar defense
> project, developing Oracle/Unix software that required *ten thousand
> hours* of development work.

My tax dollars, at work.

>=20
> So who the frig are YOU, to laugh at ME?

Someone who enjoys a good joke?

I mean, I do think it's quite funny that everything you know today will b=
e=20
completely and totally worthless in a few short years, when Microsoft wil=
l=20
unilaterally obsolete all Windows development APIs of today, replacing th=
em=20
with something that does more or less than same thing, but forcing everyo=
ne=20
to get a new version of MS Visual Studio, MSDN, documentation, etcâ€=A6

Don't you think that it's hilarious how all the teeming Minesweeper=20
Consultants and Solitaire Experts miss the fact that their primary job is =
to=20
provide a recurring revenue stream to Microsoft, and if they manage to ek=
e=20
out a living, that it's only a fortuitous coincidence? How proud they ar=
e=20
to announce their latest paper certificate in their sigs, despite that it=
,=20
like every Windows technology of yesterday, today, and tomorrow, has a=20
terminal lifespan and will be completely worthless, unless they continue =
to=20
generate revenue for Redmond. I mean, that's what happened to every othe=
r=20
bit of "innovative" technology, of the years gone by? Remember VBX? OCX=
? =20
DAO? And the rest of that alphabet soup? They're just a fond memory by=20
now. And so will be .NYET and Dâ™=AD; when their time comes and MS n=
eeds more=20
revenue.

I think that's rather funny, don't you?

> What is YOUR comparative
> experience? Please explain your personal software development
> experience. Feel free to list the number of multi-thousand hour
> development projects that you have undertaken in multi billion dollar
> software projects.

Sorry, at the moment I'm not in the job market. But, the next time I am,=20
I'll be sure to send you my CV.

>=20
> I'll try to make it easy for you. Just fill out the blanks below:
>=20
> 1.

IMAP

>=20
> 2.

POP3

>=20
> 3.

SMTP

>=20
> 4.

DNS

>=20
> 5.

HTTP

> I look forward to reading your reply.

I can assure you, that the thousands of people in hundreds of countries a=
ll=20
over the world, who, much like myself, contributed to the decades-long=20
design, development and implementation of all of these commodity protocol=
s=20
that make up the infrastructure of the Internet -- well, by comparison, y=
our=20
illustrious past doesn't amount to much more than a roadside lemonade sta=
nd.


--=_mimegpg-commodore.email-scan.com-27240-1147388309-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEY8GVx9p3GYHlUOIRAupGAJ46PNS0I8ZIbLKpflDYsJ5F5QPn+QCe INh/
5DWbGRyPmka8fao/wuqMT3M=
=MFDU
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-27240-1147388309-0001--

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:

> So it's the old question: how do I identify that mailserver, through
> code?

You can't. You have to ask the user for it. Given the experience you claimed
you have in another post, you should know that. So why are you asking?

--
David.

Re: Finding the user"s ISP"s outgoing mail server?

What a laugh!

You obviously don't feel confident to offer *ANY* comparable software
dev experience.

STFU next time.

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

Markus Zingg wrote:

> >That's what I thought. So the question is, would incoming servers
> >typically accept, or reject, *outgoing* emails?
>
> They obviousely would reject it so as they can't be abused as a relay.

I get it. The incoming server only accepts a target address within its
own network.


> [snip]
> >No problems with that. I plan to support AUTH, and POP before SMTP.
>
> Errr.. and how do you intend to find out the needed login and
> password? If you have to ask the user for this information then you
> can also ask for the propper mailserver at the same time...

Uh - good point !!


> [snip]
> >Sorry, I'm not sure if I understand that. To "get the right server"
> >means, to me, that I would somehow get the name (eg. smtp.blah.com), or
> >IP address (eg. 11.22.33.44), of the correct outgoing mailserver. How
> >would that name or address need to be "addressed differently" from the
> >PC? I don't understand what you are getting at there.
>
> Imagine a site with their own mailserver siting in the internal
> network or DMZ. Your name resolution of mail.bla.com would return the
> external IP of said organisation. It's however NOT said that if you
> try to talk to that IP from within the lan of this organisation that
> the IP would be propperly routed.

Ok, I understand.

Thanks for all that. I thought that my idea was on the ball, but
clearly not. That's why I asked the question here. :-)

Cheers,
TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

Frank Slootweg wrote:

> (snip) viri/viruses are known to get this kind of information
> from the Windows configuration (registry?). While this might not work
> for *all* possible MUAs (Mail User Agents / 'mailers'), it will probably
> work for the more *common* ones, like Outlook (Express) and probably
> also the Netscape/Mozilla family.

Yes, but I don't want to do that, because I don't require the user to
have an email client on their PC.


> The authentication issue is indeed a valid one, so perhaps you still,
> at least sometimes, have to ask the user for their (email) password(s)

Yes. As you & Markus have pointed out, I would have to prompt them for
their username/password. I could not get those details any other way.
So I might as well prompt them for the mailserver name at the same
time. The odds are that the user will not know /any/ of that
information, & will have to get it all from their ISP - in which case,
I might as well require them to enter it all (including the mailserver
name).


> I hope this helps.

Indeed, thanks for the answer.

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

Surprisingly, 30 years of software dev experience, has not make me an
acknowledged world expert, in every software protocol which has ever
existed in the history of software development.

That is why I asked the question. Hopefully, the concept of "asking a
question", to manage gaps in knowledge, is not an excessively hard
concept for you to understand. I imagine that you have probably done it
yourself, from time to time. And when you did, you probably expected an
intelligent answer, not a load of arrogant self-serving nonsense.

I must say, some of you guys are quite a class act. You should maybe
get out more.

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

>Thanks for all that. I thought that my idea was on the ball, but
>clearly not. That's why I asked the question here. :-)

I THINK you might could get away with that aproach for a significant
percentage of the installs you do. So, what you IMHO could do is
simply try to find the server this way, send a test message to an
e-mail address of yours which then triggers "something" your
installation programm can query. I.e. if you setup a specialized
mailserver at your location it could perpare a website your
installation programm would query after sending the testmail. If it
finds the page, your software knowns all worked right and it could
silently continue. If the page is not found within a given timeout
period you would have to prompt the user (or disable that function etc
etc.)

That's probably how I would do it if the functionality would seem
worthwile to me.

HTH

Markus

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:
>
> Frank Slootweg wrote:
>
> > (snip) viri/viruses are known to get this kind of information
> > from the Windows configuration (registry?). While this might not work
> > for *all* possible MUAs (Mail User Agents / 'mailers'), it will probably
> > work for the more *common* ones, like Outlook (Express) and probably
> > also the Netscape/Mozilla family.
>
> Yes, but I don't want to do that, because I don't require the user to
> have an email client on their PC.

OOPS! Sorry about that. I had overlooked that fact in your original
posting. BTW, you probably mean they don't have a *configured* email
client on their PC, because, if the platform is indeed (MS-)Windows,
they most likely will have Outlook Express (whether they know it or not
and whether it's 'visible' or not), because most people don't know how
to remove OE without causing problems.

But of course for your application, an unconfigured email client is
effectively the same as an absent one, so it makes no difference.

[deleted]

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-5922-1147429518-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

TC writes:

> What a laugh!

What are you laughing about, exactly? As you can see, everyone else here
always quotes portions of the previous message, in their reply, so that the
context is obvious.

> You obviously don't feel confident to offer *ANY* comparable software
> dev experience.

I agree: my experience does not have anything comparable to having to
forcibly generate revenue for a convicted monopolist.

> STFU next time.

You would be wise to follow your own advice, when confronted by your mental
superiors. Don't forget: you are the one that came here, pleading ignorance
of basic Internet protocols.

> TC (MVP MSAccess)

Minesweeper/Solitaire access?

> http://tc2.atspace.com
>

--=_mimegpg-commodore.email-scan.com-5922-1147429518-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEZGKOx9p3GYHlUOIRAvtFAJ49jCdXOzyEOY3bxjcZWKtUuwprJQCf b6e5
RdtHFEZd1qf+J3Dqkm2elLk=
=1EHi
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-5922-1147429518-0001--

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-5922-1147429572-0002
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg

TC writes:

>=20
> Markus Zingg wrote:
>=20
>> >That's what I thought. So the question is, would incoming servers
>> >typically accept, or reject, *outgoing* emails?
>>
>> They obviousely would reject it so as they can't be abused as a relay.
>=20
> I get it. The incoming server only accepts a target address within its
> own network.

Bravo! 30 years of software development experience has finally paid off.

>> [snip]
>> >No problems with that. I plan to support AUTH, and POP before SMTP.
>>
>> Errr.. and how do you intend to find out the needed login and
>> password? If you have to ask the user for this information then you
>> can also ask for the propper mailserver at the same time...
>=20
> Uh - good point !!

And the hits just keep on comingâ€=A6



--=_mimegpg-commodore.email-scan.com-5922-1147429572-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEZGLEx9p3GYHlUOIRAs/JAJ9T7euaqs4J1Gjuc0CPw1mHReZrsgCc D41j
zGUW3t9d6L1TDsckEPaBRSU=
=WD8N
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-5922-1147429572-0002--

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-5922-1147429737-0003
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

TC writes:

> question", to manage gaps in knowledge, is not an excessively hard
> concept for you to understand. I imagine that you have probably done it
> yourself, from time to time. And when you did, you probably expected an
> intelligent answer, not a load of arrogant self-serving nonsense.

When I did it, I did not make it point of flaunting my ignorance in my sig.

> I must say, some of you guys are quite a class act. You should maybe
> get out more.

We need to introduce you to Beavis, the resident kookbag of this newsgroup.
I have a hunch that you two will hit it off.


--=_mimegpg-commodore.email-scan.com-5922-1147429737-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEZGNpx9p3GYHlUOIRAn9BAJ0bKMARFheg5rs14WpOlBTPocH4nwCe PC6x
ppUrKSutPVTMy+Ba6MbyXjY=
=WiHQ
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-5922-1147429737-0003--

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:

> Surprisingly, 30 years of software dev experience, has not make me an
> acknowledged world expert, in every software protocol which has ever
> existed in the history of software development.

:-) OK.

Given your constraints, you need to rethink the problem. *why* does
your software need to send out e-mail? Can you do it another way?
(For example, have your software POST to an HTTPS web page that you control,
and have your web server send out the mail.)

It's probably easier for you to get the information in a way in which you
control everything rather than relying on the user's ISP for anything.

> I must say, some of you guys are quite a class act. You should maybe
> get out more.

Perhaps you don't realize that "MVP MSAccess" carries negative weight amongst
most Usenet types, leaving you open to mockery.

By the way, there are Windoze viruses out there that have their own SMTP engine,
and they probably have a mechanism to detect filtered SMTP ports and react by relaying
through the ISP's mail server. Perhaps you should grab one and study it?

--
David.

Re: Finding the user"s ISP"s outgoing mail server?

Yes, that is worth considering.

I'm wondering, now, whether I should assume that most of the users
*will* have an email client on their PC. Most of them probably will. I
could display a list of clients (Outlook, Outlook Express, Eudora,
etc.) and ask them to select the one they use. Then I could get the
relevant information from the registry, using the keys specific to that
product.

Alternatively I could have my install program create a text file for
them to send to their ISP as an email. The text would ask the ISP for
the relevant details & explain why those were required.

It's clearly going to be harder than I though it would! Thanks for the
help,

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

And that is the best you can do as a put-down response?

Bzzzt, goodbye.

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:
> Hi folks
>
> I'm adding email functionality to a software application. Each user is
> known to be "connected to the internet", but they do not necessarily
> have an email client on their PC. So I'm planning to add an SMTP
> component to the application, to send the email directly to the
> outgoing mailserver of the user's ISP.
>
> So it's the old question: how do I identify that mailserver, through
> code?
>
> Here's my plan. AFAIK, most (all?) ISPs give their users an email
> address. What if I ask the user to enter that email address, and then I
> do an MX query on the domain of that address? Eg. the user enters
> "me@blah.com", and I do an MX query on "blah.com", and use the result
> as the SMTP server address?
>
> AFAICS, this would *have to* return the address of the user's ISP's
> *incoming* mail server, since it is the same method that other
> mailservers use, to get that information. But I wonder would the same
> address would generally work for *outgoing* emails? That is, *if* the
> ISP had different mailservers for incoming & outgoing email, could I
> expect to send emails via their *incoming* mailserver (the one
> identified by my process abve), or would that usually be rejected?

This will be wrong for a significant percentage of cases. You might
also try "smtp" or "mail" as hostnames (let DNS fill in the domain). I
think between the three possibilities you would probably cover better
than two thirds of cases, but you would still need to give the user the
opportunity to enter a hostname. It is easy to see if you can get an
MTA banner at port 25 of a host, to confirm you are right. As others
have pointed out, this isn't much help if the MTA requires
authentication, but that really isn't very common.

A good list of outgoing smtp servers for various ISPs all over the
world is at http://www.iw-webhosting.co.uk/smtp_hosts.htm . You can see
from that list how popular "smtp" and "mail" are as hostnames for the
smarthost, but they are not universal. Several other such lists are
mentioned at http://www.nber.org/sys-admin/smarthost.html .

Surprisingly, the smtp server name doesn't seem to be anywhere in the
windows registry, at least on win2k, which I just checked.

Daniel Feenberg
feenberg isat nber dotte org

>
> TIA,
> TC (MVP MSAccess)
> http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

In retrospect, I think that I'm being overly pessimistic with this.
When I think about my client base, sending email is probably their
*main reason* for being connected to the internet! So they probably
*do* have a configured email client on their PC.

I'll do a survey to see what email client (if any) most of them use. If
99% of them say that they do use email, and they use Outlook or Outlook
Express for that, then I could probably code for those two case, and
handle the exceptions by some other means.

Thanks for the input,

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

David F. Skoll wrote:
> TC wrote:
>
> > Surprisingly, 30 years of software dev experience, has not make me an
> > acknowledged world expert, in every software protocol which has ever
> > existed in the history of software development.
>
> :-) OK.
>
> Given your constraints, you need to rethink the problem. *why* does
> your software need to send out e-mail? Can you do it another way?
> (For example, have your software POST to an HTTPS web page that you control,
> and have your web server send out the mail.)

Ok, I hadn't thought of that. At present, my product support website
(which is not the one in my sig) would not be able to do that. But I'll
certainly give that suggestion some thought. My software has to take
actions which result in emails being received by people; but that is
not to say that it must actually send those emails *itself*.


> It's probably easier for you to get the information in a way in which you
> control everything rather than relying on the user's ISP for anything.

That is cerainly an aim that I would like to achieve.


> > I must say, some of you guys are quite a class act. You should maybe
> > get out more.
>
> Perhaps you don't realize that "MVP MSAccess" carries negative weight amongst
> most Usenet types, leaving you open to mockery.

Then "most usenet types" are idiots. MS Access is a highly capable
desktop database management system. I say this as a professional
corporate database software developer with many years experience in
heavy-duty database management systems. People who deride MS Access are
generally ignoramuses, who know nothing about it. Really, there are
people who think the earth is flat, or the end of the world is
tomorrow, or it's immoral to wear red clothes on Thursdays. Do you
listen to them also?


> By the way, there are Windoze viruses out there that have their own SMTP engine,
> and they probably have a mechanism to detect filtered SMTP ports and react by relaying
> through the ISP's mail server. Perhaps you should grab one and study it?

Hmm, not a bad idea, but I'll pursue the other ones first!

Thanks for the input,

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

Ok, thanks for those suggestions & lists.

I particularly like the idea of doing a preliminary connect to the
proposed MTA & doing some extra parsing of what it returns. I will look
into that further.

Cheers,
TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-4539-1147537267-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

TC writes:

> And that is the best you can do as a put-down response?

Can't answer that. Unlike everyone else in this newsgroup (or Usenet, for
that matter), you fail to cite the contents of the previous post that you
are replying to. Seems that, despite your 30 years of software development
experience, that simple task is beyond your abilities.

> Bzzzt, goodbye.

By the way, do you have any relatives in Oklahoma?

http://www.theregister.com/2006/03/30/tuttle_fbi_pledge/


--=_mimegpg-commodore.email-scan.com-4539-1147537267-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEZgdzx9p3GYHlUOIRAnloAJ9QyUbeChOhDuzxj5TaayKLPLDPaQCa A6P4
8RZnRChPemX7EmAJyDwCbFo=
=HpnE
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-4539-1147537267-0001--

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:
>
> David F. Skoll wrote:
[deleted]

> > Perhaps you don't realize that "MVP MSAccess" carries negative
> > weight amongst most Usenet types, leaving you open to mockery.
>
> Then "most usenet types" are idiots. MS Access is a highly capable
> desktop database management system. [deleted]

Of course I don't know for sure what David meant, but he probably
meant any and all part(s) of "MVP MSAccess". I.e. the "MS" part, the
"MVP" part, and probably only to a lesser extent the "Access" part.

But don't worry, "most Usenet types" *aren't* zealots.

For example you don't see me mocking people [1] who apparently have
broken newsreaders or don't know how to use them. OOPS! :-)

[deleted]

[1] No, *not* you/TC.

Re: Finding the user"s ISP"s outgoing mail server?

In article <1147533215.794972.298570@y43g2000cwc.googlegroups.com>,
TC wrote:
:Ok, thanks for those suggestions & lists.
:
:I particularly like the idea of doing a preliminary connect to the
:proposed MTA & doing some extra parsing of what it returns. I will look
:into that further.

If the computer is portable, another thing to consider is that a
mail server that accepts connections without authorization when the
connection comes from within the ISP's network will almost certainly
require authorization if the computer is taken "on the road" and the
server sees the connection coming from a foreign network.

--
Bob Nichols AT comcast.net I am "RNichols42"

Re: Finding the user"s ISP"s outgoing mail server?

Robert Nichols wrote:
> In article <1147533215.794972.298570@y43g2000cwc.googlegroups.com>,
> TC wrote:
> :Ok, thanks for those suggestions & lists.
> :
> :I particularly like the idea of doing a preliminary connect to the
> :proposed MTA & doing some extra parsing of what it returns. I will look
> :into that further.
>
> If the computer is portable, another thing to consider is that a
> mail server that accepts connections without authorization when the
> connection comes from within the ISP's network will almost certainly
> require authorization if the computer is taken "on the road" and the
> server sees the connection coming from a foreign network.

Hi Robert

I hear what you say. Very few of my users would have my software on a
mobile PC. Most or all of the copies would be on a desktop PC.

However, I'll accomodate your scenario in the following way.
Previously, I planned to have authentication fields (ie.
username/password) which had to be entered if the mailserver required
authentication, or left blank if it didn't. Now I'll consider using a
"profile" approach, where the software can have several profiles, and
authentication might be required in certain profiles but not in others.
Then the user could select the appropriate profile manually, or maybe
the software could do it automagically - eg. by checking the PC's
docking status, or somesuch.

Thanks for the input.

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:

[...]

> Ok, I hadn't thought of that. At present, my product support website
> (which is not the one in my sig) would not be able to do that. But I'll
> certainly give that suggestion some thought. My software has to take
> actions which result in emails being received by people; but that is
> not to say that it must actually send those emails *itself*.

You'll be much happier with more of the infrastructure under your
control. Even attempting SMTP connections to "likely" hosts is
fraught with danger; some ISPs invisibly proxy outbound SMTP
connections to their own hosts, meaning you have no idea what you're
connecting to. In my experience, relying as little on the end-user PC
and as much on my own (reliable, well-controlled) servers makes my
life much happier. (You should read Paul Graham's "Hackers and Painters",
especially the chapter describing his web-based software product.)

[... snip ...]

> Then "most usenet types" are idiots. MS Access is a highly capable
> desktop database management system.

If you say so. It's just that in my experience, as an owner of a
software development company and someone who has been responsible for
hiring software developers, people who advertise MS credentials are
generally not worth hiring.

I stress that this is just *my* limited experience, but for me, it has
been a remarkably consistent indicator.

> People who deride MS Access are
> generally ignoramuses, who know nothing about it.

I'm not deriding MS Access specifically, though I do believe it's a
toy compared to a real database like PostgreSQL. I'm just sharing my
experience with people who advertise MS credentials.

--
David.

Re: Finding the user"s ISP"s outgoing mail server?

In article , Sam wrote:
>> So it's the old question: how do I identify that mailserver, through
>> code?
>
> You can't. The name of the user's smarthost is determined entirely by the
> user's ISP.

Wrong.

--
--Tim Smith

Re: Finding the user"s ISP"s outgoing mail server?

Care to elucidate?

TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

David F. Skoll wrote:
> TC wrote:
>
> [...]
>
> > Ok, I hadn't thought of that. At present, my product support website
> > (which is not the one in my sig) would not be able to do that. But I'll
> > certainly give that suggestion some thought. My software has to take
> > actions which result in emails being received by people; but that is
> > not to say that it must actually send those emails *itself*.
>
> You'll be much happier with more of the infrastructure under your
> control. Even attempting SMTP connections to "likely" hosts is
> fraught with danger; some ISPs invisibly proxy outbound SMTP
> connections to their own hosts, meaning you have no idea what you're
> connecting to. In my experience, relying as little on the end-user PC
> and as much on my own (reliable, well-controlled) servers makes my
> life much happier. (You should read Paul Graham's "Hackers and Painters",
> especially the chapter describing his web-based software product.)

Ok, thanks for that info, I will do my best to get & read that book.
However, the downside is, that my product would then rely on one
external server. This would constitute a single point of failure. With
the "user's ISP's mailserver" approach, there is no single point of
failure.

> > Then "most usenet types" are idiots. MS Access is a highly capable
> > desktop database management system.
>
> If you say so. It's just that in my experience, as an owner of a
> software development company and someone who has been responsible for
> hiring software developers, people who advertise MS credentials are
> generally not worth hiring.

The problem IMHO is that there is no bar to entry, using MS Access.
Anyone can grab a copy & start hacking away. As a result, there are
lots of MS Access systems that have been written by amatuers with no
software dev experience. So the database schema is completely incorrect
(they have never heard of normalization), the queries all use SELECT
DISTINCT (to handle unexpected duplicate records), so none of the
queries are updatable (which restricts their use in data entry forms),
the code is hopelessly bad (no indenting, no comments, heavy use of
global variables), the user interface is non-standard & badly designed,
the software hs not been properly tested & is full of bugs & problems,
and so on.

BUT: none of that is MS Access'es fault! You could make exactly the
same mistakes with SQL*Server, Oracle, or any other industrial-strength
DBMS. The reason that this does not generally occur, with those other
database products, is simply that their bar to entry is much higher. So
they tend to be used only by people with proer software dev experience.
For example, until relatively recently, there would have been very few
people with Oracle running on their PC! - so there is much less
opportunity for random unskilled people to write horrible Oracle
systems.

In conclusion (gasp), there is absolutely nothing whatever inherent in
MS Access that leads to these problems. It's like me building a
bookshelf with my non-existent carpentry skills. The shelves wouldn't
fit, it wouldn't be square, and the whole thing would collapse as soon
as you put some heavy books on it. But that would not be a criticism of
hammers, nails, saws, screws, and the other tools that I had used to
build it!

Cheers,
TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-26467-1147690443-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Tim Smith writes:

> In article , Sam wrote:
>>> So it's the old question: how do I identify that mailserver, through
>>> code?
>>
>> You can't. The name of the user's smarthost is determined entirely by the
>> user's ISP.
>
> Wrong.

Right.



--=_mimegpg-commodore.email-scan.com-26467-1147690443-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEaF3Lx9p3GYHlUOIRAgaWAJ95UjKtCClJgabUNnIbjU8u348TVwCf Ybl+
HrVKUsfW++dBOFIFqtUv0IQ=
=dXE5
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-26467-1147690443-0002--

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:

> Ok, thanks for that info, I will do my best to get & read that book.
> However, the downside is, that my product would then rely on one
> external server. This would constitute a single point of failure. With
> the "user's ISP's mailserver" approach, there is no single point of
> failure.

You can run redundant servers, and have your software try them in sequence
(or randomly, for load-balancing.)

--
David.

Re: Finding the user"s ISP"s outgoing mail server?

David F. Skoll wrote:
> TC wrote:
>
> > Ok, thanks for that info, I will do my best to get & read that book.
> > However, the downside is, that my product would then rely on one
> > external server. This would constitute a single point of failure. With
> > the "user's ISP's mailserver" approach, there is no single point of
> > failure.
>
> You can run redundant servers, and have your software try them in sequence
> (or randomly, for load-balancing.)

Agreed, but I'm not sure that I want to go that route. At present my
software does not rely on *any* external servers. It's a typical,
standalone desktop product. But I hear what you say, I will think about
your suggestion some more.

Cheers,
TC (MVP MSAccess)
http://tc2.atspace.com

Re: Finding the user"s ISP"s outgoing mail server?

"TC" wrote:
> So it's the old question: how do I identify that mailserver, through
> code?

Sam replied:
> You can't. The name of the user's smarthost is determined entirely by the
> user's ISP.

Tim Smith objected:
> Wrong.

and the conversation seemed to go further downhill...

Tim, were you referring to the case where the user's PC was on a LAN,
with a mailserver on that LAN, and the whole thing was firewalled to
ensure that outgoing e-mail had to use that mailserver as a smart host
(said mailserver then forwarding though an ISP's smarthost or not as
appropriate?)

Or were you referring to the case where a user preferred using gmail's
smarthost rather than their own ISP's smarthost?

James.

--
E-mail address: james | "The letters are Elvish, of an ancient mode, but the
@westexe.demon.co.uk | language is that of Microsoft, which I will not utter
| here. But this in the Common Tongue is what is said:
| By this or any other name, You are well and truly..."

Re: Finding the user"s ISP"s outgoing mail server?

TC wrote:

> Agreed, but I'm not sure that I want to go that route. At present my
> software does not rely on *any* external servers.

Err... yes it does. It relies on an ISP's SMTP server, and you have no
idea where that server is or how reliable it may be.

Regards,

David.