SMTP Client

I am starting a new project to create a SMTP Client for Windows; I am
using the winsock2 library. When I use the following commands I get an
error (550):

220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
HELO world
250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
MAIL FROM: test@test.com
250 OK
RCPT TO: test@gmail.com
550 authentication required
QUIT
221 ns1.zanmo.com closing connection

Please explain how to authenticate the session, and how do I
Programmatically MX Lookup also using MX record?

On 9 Feb, 02:07, J <seaworthyjer...@gmail.com> wrote:
> I am starting a new project to create a SMTP Client for Windows; I am
> using the winsock2 library. When I use the following commands I get an
> error (550):
>
> 220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
> HELO world
> 250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
> MAIL FROM: t...@test.com
> 250 OK
> RCPT TO: t...@gmail.com
> 550 authentication required
> QUIT
> 221 ns1.zanmo.com closing connection
>
> Please explain how to authenticate the session, and how do I
> Programmatically MX Lookup also using MX record?

try a better newsgroup. Maybe a microsoft one

In article <d08c0ea2-83a5-48ab-8c19-ac9e7c9adf52@21g2000yqj.googlegroups.com>,
J <seaworthyjeremy@gmail.com> wrote:

>Please explain how to authenticate the session

See http://tools.ietf.org/rfc/rfc4954.txt

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Op 9-2-2010 10:27, Nick Keighley schreef:
> On 9 Feb, 02:07, J <seaworthyjer...@gmail.com> wrote:
>> I am starting a new project to create a SMTP Client for Windows; I am
>> using the winsock2 library. When I use the following commands I get an
>> error (550):
>>
>> 220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
>> HELO world
>> 250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
>> MAIL FROM: t...@test.com
>> 250 OK
>> RCPT TO: t...@gmail.com
>> 550 authentication required
>> QUIT
>> 221 ns1.zanmo.com closing connection
>>
>> Please explain how to authenticate the session, and how do I
>> Programmatically MX Lookup also using MX record?
>
> try a better newsgroup. Maybe a microsoft one

microsoft does not do,

this suggegtion comes as close as redirecting someone who askes about C
to 'Borland', because they write (or wrote?) c-compilers...

--
Luuk

On Mon, 08 Feb 2010 18:07:26 -0800, J wrote:

> I am starting a new project to create a SMTP Client for Windows; I am
> using the winsock2 library. When I use the following commands I get an
> error (550):
>
> 220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
> HELO world
> 250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
> MAIL FROM: test@test.com
> 250 OK
> RCPT TO: test@gmail.com
> 550 authentication required
> QUIT
> 221 ns1.zanmo.com closing connection
>
> Please explain how to authenticate the session,

http://tools.ietf.org/html/rfc4954

More generally:

http://en.wikipedia.org/wiki/SMTP#Re...s_For_Comments

> and how do I
> Programmatically MX Lookup also using MX record?

Dunno, but DnsQuery() looks promising. If you want a better answer, ask on
a Windows group.

On 9 Feb, 10:41, Luuk <l...@invalid.lan> wrote:
> Op 9-2-2010 10:27, Nick Keighley schreef:
> > On 9 Feb, 02:07, J <seaworthyjer...@gmail.com> wrote:

> >> I am starting a new project to create a SMTP Client for Windows; I am
> >> using the winsock2 library. When I use the following commands I get an
> >> error (550):
>
> >> 220 ns1.zanmo.com ESMTP Exim 4.69 Mon, 08 Feb 2010 17:58:41 -0800
> >> HELO world
> >> 250 ns1.zanmo.com Hello 60.sub-75-229-11.myvzw.com [75.229.11.60]
> >> MAIL FROM: t...@test.com
> >> 250 OK
> >> RCPT TO: t...@gmail.com
> >> 550 authentication required
> >> QUIT
> >> 221 ns1.zanmo.com closing connection
>
> >> Please explain how to authenticate the session, and how do I
> >> Programmatically MX Lookup also using MX record?
>
> > try a better newsgroup. Maybe a microsoft one
>
> microsoft does not do,
>
> this suggegtion comes as close as redirecting someone who askes about C
> to 'Borland', because they write (or wrote?) c-compilers...

<shrug> he said he was developing a for windows so I thought a windows
might be some use. I must admit I didn't understand his question.

On Wed, 10 Feb 2010 04:47:26 +0100, Tor Rustad wrote:

> Now what does authentication mean? Well, the server like to know *who*
> the client is, but hey if that is done via a *shared secret*, isn't it a
> pretty bad idea to send such important info out in the great void, also
> known as internet???

It's an improvement over running an open relay.

There's only so much to be gained from better security when a good
proportion of your users are likely to be infested with malware.

Nobody wrote:
> On Wed, 10 Feb 2010 04:47:26 +0100, Tor Rustad wrote:
>
>> Now what does authentication mean? Well, the server like to know *who*
>> the client is, but hey if that is done via a *shared secret*, isn't it a
>> pretty bad idea to send such important info out in the great void, also
>> known as internet???
>
> It's an improvement over running an open relay.

SPAM will not stop by using weak authentication.

> There's only so much to be gained from better security when a good
> proportion of your users are likely to be infested with malware.

Malware can do little about a proper design.

For example, within the year, banks all over the world will convert
their VISA and MasterCard products from SDA (static data authentication)
chip, to DDA (dynamic data authentication) chip.

This DDA chip is capable of doing RSA computations and have room for
more applications, like e.g. authentication application, which can be
now be far more advanced than an one-time-password generator.

The hard part, is really establishing the HW infrastructure, not the SW
side of things! My latest laptop came with a chip card reader, you can
also attach such reader device via USB.

So the technology is here, and it's being rolled out as we speak.

--
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

On Wed, 10 Feb 2010 07:29:19 +0100, Tor Rustad wrote:

>>> Now what does authentication mean? Well, the server like to know *who*
>>> the client is, but hey if that is done via a *shared secret*, isn't it a
>>> pretty bad idea to send such important info out in the great void, also
>>> known as internet???
>>
>> It's an improvement over running an open relay.
>
> SPAM will not stop by using weak authentication.

Nor will it stop by using strong authentication, at least not without
also securing the rest of the system, and that isn't likely to happen.

Tor Rustad <bwzcab@wvtqvm.vw> wrote:
<snip>
> The hard part, is really establishing the HW infrastructure, not the SW
> side of things! My latest laptop came with a chip card reader, you can
> also attach such reader device via USB.

> So the technology is here, and it's being rolled out as we speak.

I disagree. The hard part is the software side. I bought a pack of 10 secure
Schlumberger cryptocards over 8 years ago, and the _software_ support is
still abysmal (and still largely in the same shape then as now). The USB
controller was even built into the chip, and a plastic keyfob was all but
free (you could pop the chip from the credit-card sized packaging and insert
it into the keyfob). Very nice hardware; very inexpensive. Projects like
OpenSC, etc, just don't get any attention, however.

The standards are there, too. PKCS-11. X.509. Client-side signed
certificates. Heck, even the OpenSSH folks aren't particularly interested in
integrating PKCS support.

Nope. The lack of use, I'd argue, is entirely a function of poor and
confusing software support, and simple ambivalence and laziness.

Nobody wrote:
> On Wed, 10 Feb 2010 07:29:19 +0100, Tor Rustad wrote:
>
>>>> Now what does authentication mean? Well, the server like to know *who*
>>>> the client is, but hey if that is done via a *shared secret*, isn't it a
>>>> pretty bad idea to send such important info out in the great void, also
>>>> known as internet???
>>> It's an improvement over running an open relay.
>> SPAM will not stop by using weak authentication.
>
> Nor will it stop by using strong authentication, at least not without
> also securing the rest of the system, and that isn't likely to happen.

Internet will not stay insecure forever, and strong authentication will
be forced upon us, sooner or later. Sooner, the more we depend on it.

Securing server side, is the lesser challenge in this picture.

--
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

William Ahern wrote:
> Tor Rustad <bwzcab@wvtqvm.vw> wrote:
> <snip>
>> The hard part, is really establishing the HW infrastructure, not the SW
>> side of things! My latest laptop came with a chip card reader, you can
>> also attach such reader device via USB.
>
>> So the technology is here, and it's being rolled out as we speak.
>
> I disagree. The hard part is the software side. I bought a pack of 10 secure
> Schlumberger cryptocards over 8 years ago, and the _software_ support is
> still abysmal (and still largely in the same shape then as now). The USB
> controller was even built into the chip, and a plastic keyfob was all but
> free (you could pop the chip from the credit-card sized packaging and insert
> it into the keyfob). Very nice hardware; very inexpensive. Projects like
> OpenSC, etc, just don't get any attention, however.
>
> The standards are there, too. PKCS-11. X.509. Client-side signed
> certificates. Heck, even the OpenSSH folks aren't particularly interested in
> integrating PKCS support.
>
> Nope. The lack of use, I'd argue, is entirely a function of poor and
> confusing software support, and simple ambivalence and laziness.

Without HW, SW is useless.

There is a major difference between having a developer kit, and get to a
point where all PC's ship with a good smartcard reader. 8 years ago, the
banks lacked secure production line for smartcards, and the financial
networks lacked smartcard accepting readers. That has changed, and today
your mobile may even be sporting a 32K PKI enabled smartcard. In a few
years now, we will all have strong authentication enabled cards/SIM,
capable of running multiple applications. Beside Telecom and Banks, the
public sector will use more and more secure ID cards.

This has taken a long time, the Europay MasterCard VISA (EMV) specs came
in 1996, if it was just a matter of developing some SW, the transition
would have been completed years ago. Upgrading HW world-wide is a
different ballgame, and I bet there is still quite a few devices out
there, not yet accepting my VISA on chip.

It must be 10 years ago I read an article in a smartcard magazine called
"PKI nothing more than pilots". At that time, I had worked with PKI for
years, by establishing secure infrastructure for transactions over open
networks via SET.

We had *everything* ready for roll-out, merchant SW, client SW, payment
gateway, client certificate enrollment... the full package and almost
nothing happened.

Why?

First of all, as a security infrastructure, it had a major flaw, namely
on the client side all keys and crypto was done in SW, and equally
important, it required installing special fat client on all user PC's. A
support nightmare, so the banks skipped the client/wallet first, as the
client added little to no security, without a HW token anyway.

Hence, prior to year 2000 several vendors had implemented the complex
SET protocol, sporting several PKCS standards, the whole spec was in
ASN.1, where every message was DER encoded. There was also an open
source reference implementation in C, from VISA.

To make a long story short, we ended up using the complex SET protocol
over a 2m cable in our own computing base, and it was SOON replaced by a
lightweight security toolkit I wrote, which enabled merchants on
internet to communicate with the financial network in a far more
efficient way.

SET wasn't even a pilot, and the concept of non-repudiation was a joke.

--
Tor <echo bwzcab@wvtqvm.vw | tr i-za-h a-z>

Tor Rustad <bwzcab@wvtqvm.vw> wrote:
> William Ahern wrote:
<snip>
> > I disagree. The hard part is the software side. I bought a pack of 10 secure
> > Schlumberger cryptocards over 8 years ago, and the _software_ support is
> > still abysmal (and still largely in the same shape then as now). The USB
> > controller was even built into the chip, and a plastic keyfob was all but
> > free (you could pop the chip from the credit-card sized packaging and insert
> > it into the keyfob). Very nice hardware; very inexpensive. Projects like
> > OpenSC, etc, just don't get any attention, however.
> >
> > The standards are there, too. PKCS-11. X.509. Client-side signed
> > certificates. Heck, even the OpenSSH folks aren't particularly interested in
> > integrating PKCS support.
> >
> > Nope. The lack of use, I'd argue, is entirely a function of poor and
> > confusing software support, and simple ambivalence and laziness.

> Without HW, SW is useless.

> There is a major difference between having a developer kit, and get to a
> point where all PC's ship with a good smartcard reader. 8 years ago, the
> banks lacked secure production line for smartcards, and the financial
> networks lacked smartcard accepting readers.

My Schlumberger cards (w/ secure onboard key generation and signing) had a
built-in USB controller. The chip fit into a cheap, key-chain sized keyfob
that you plugged directly into the USB port. Altogether the card plus keyfob
was less than US $5, though I wasn't buying in volume.

This chip could then be used to create client-side SSL certificates and
setup authenticated/signed TLS sessions. Mozilla actually had some PKCS
support, so theoretically you could plug the keyfob into the USB port, and
then visit any SSL-enabled website. The website code (PHP, Coldfusion, Java,
w'ever) could then verify the client certificate using standard APIs already
exposed by any SSL/TLS implementation. The problem was that the stack wasn't
complete on the client side. While theoretically all that was needed was to
plug the keyfob into the port, the kernel (Windows, OS X, and Linux) USB
controllers and PKCS#11/15 libraries didn't work well w/ each other. And
they still don't.

> That has changed, and today your mobile may even be sporting a 32K PKI
> enabled smartcard. In a few years now, we will all have strong
> authentication enabled cards/SIM, capable of running multiple
> applications. Beside Telecom and Banks, the public sector will use more
> and more secure ID cards.

Indeed, all kinds of devices have crypto chips (to varying degrees of
sophistication) built-in. But the same problems remain: they're largely
inaccesible by your web browser, OpenSSH client, or what have you, w/o some
serious hacking.

> This has taken a long time, the Europay MasterCard VISA (EMV) specs came
> in 1996, if it was just a matter of developing some SW, the transition
> would have been completed years ago. Upgrading HW world-wide is a
> different ballgame, and I bet there is still quite a few devices out
> there, not yet accepting my VISA on chip.

Ah, but this is a different problem. Not lack of hardware, but a plethora of
hardware. A plethora of stupid hardware driven by companies trying to
capture the market w/ proprietary, patented, and ass-backwards protocols.

Client-side X.509 certificates over SSL/TLS solve 99% of the transactional
problems, and fits in seamlessly w/ existing infrastructure. But instead of
bridging the gap between the browser (and similar software) and the chip,
vendors continue to write and rely on extraneous and superfluous software
solutions which reside outside the predominate networking stack.

> It must be 10 years ago I read an article in a smartcard magazine called
> "PKI nothing more than pilots". At that time, I had worked with PKI for
> years, by establishing secure infrastructure for transactions over open
> networks via SET.

> We had *everything* ready for roll-out, merchant SW, client SW, payment
> gateway, client certificate enrollment... the full package and almost
> nothing happened.

> Why?

> First of all, as a security infrastructure, it had a major flaw, namely
> on the client side all keys and crypto was done in SW, and equally
> important, it required installing special fat client on all user PC's. A
> support nightmare, so the banks skipped the client/wallet first, as the
> client added little to no security, without a HW token anyway.

Like I said, my Schlumberger cards were secure chips; key generation and
signing occured on-chip, and could not be recovered unless you broke out the
chemicals and microscopes. By the time I purchased mine 8 years ago they
were already a couple of years old. Schlumberger also wasn't the only vendor
of these type of chips. One notable problem was that product differentation
was weak; it was difficult to tell which chips were truly secure, and which
were glorified flash drives. This was compounded by the Java hype. One
vendor might have two versions of a card: one w/ a secure crypto chip and
another where the keys were accessible; but the chief "feature" was the tiny
Java VM and advertised Java integration. Which goes back to my original
complaint. Companies did then and still do do now focus on implementing
solutions outside the existing HTTP/TLS stack. It's sort of a catch-22. They
can't or won't coax Microsoft or Mozilla into fixing PKCS (or [insert
standard here]) integration, and yet any other software solution will never
benefit from the ubiquity and leverage one gets from a solution that uses
the existing stack.

> Hence, prior to year 2000 several vendors had implemented the complex
> SET protocol, sporting several PKCS standards, the whole spec was in
> ASN.1, where every message was DER encoded. There was also an open
> source reference implementation in C, from VISA.

> To make a long story short, we ended up using the complex SET protocol
> over a 2m cable in our own computing base, and it was SOON replaced by a
> lightweight security toolkit I wrote, which enabled merchants on
> internet to communicate with the financial network in a far more
> efficient way.

> SET wasn't even a pilot, and the concept of non-repudiation was a joke.

This all still ultimately sounds to me like a software issue. But I totally
sympathize w/ the frustration.