SMTP Client
J
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: te...@test.com
250 OK
RCPT TO: te...@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?
Nick Keighley
> 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]
> 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
Richard Tobin
J <seawort...@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.
Luuk
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
Nobody
> 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: te...@test.com
> 250 OK
> RCPT TO: te...@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#Related_Requests_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.
Nick Keighley
<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.
Tor Rustad
Why not take a look at EHLO and AUTH commands in a relevant RFC???
How to authenticate a session is way off-topic, but the starting point
for the rest of the world, would be to google for e.g. "SMTP
Authentication Tutorial". Right?
<rant>
I wouldn't say the AUTH PLAIN and the AUTH CRAM-MD5 mechanisms provide
real authentication, and the really hysterical thing is that even
running it over TLS/SSL is fundamentally flawed as well.
There is no way to establish a secure channel, unless there is mutual
authentication, so basically what you ask i.e. *how to authenticate a
session*, is an impossible task now. Your mail provider could support
2-way authentication mechanism, which he don't and if he did, you would
be using some crappy library code, which may have all kind of faults in
it. Just read one pen-test report, and you will see that bugs in crypto
libraries, is rather common.
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???
Yup, so the folks add some challenge-response stuff via CRAM-MD5, but
since you have no way of knowing which server you really are talking
to.. you might send
MD5(('secret' XOR opad), MD5(('secret' XOR ipad), challenge))
to a very happy man-in-the-middle, and of course, brute-force attacking
that shared secret isn't rocket science either.
</rant>
--
Tor <echo bwz...@wvtqvm.vw | tr i-za-h a-z>
Nobody
> 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.
Tor Rustad
> 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.
Nobody
>>> 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.
William Ahern
<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.
Tor Rustad
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 Rustad
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.
William Ahern
> 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.