Mailing List Archive

-----Original Message-----
From: alan [mailto:spfdiscuss@alandoherty.net]
Sent: woensdag 13 mei 2009 20:08
To: spf-discuss@v2.listbox.com
Subject: Re[10]: [spf-discuss] Trying to understand the best recommendation
for my client, help appreciated.

> ... just one word of advice don't be like 90% of MTA admins and
> completely disregard the mandatory need for SPF for your EHLO/HELO
> greeting ID.

They've probably been disregarding it, because there is NO such mandatory
need. From RFC 4408:

2.1. The HELO Identity

It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
identity, but also separately check the "HELO" identity by applying
the check_host() function (Section 4) to the "HELO" identity as the
<sender>.

> if you do you will seem to any of us compliance extremists just to be
> another spambot as no other SPF checks are considered trusted if HELO/EHLO
> doesn't pass.

That's an utterly ignorant statement. For all the (loud) grandstanding
you've been doing for the last few days, perhaps you ought to do well and
get your own affairs in order first.

- Mark



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> if the answer given is wrong explain how the manual indicates it
> the very method to use to set the envelope-sender

*sigh* Among other details, MSDN indicates that the apparent sendemail
property in Configuration.Fields is one of several macros for the
Sender property on the Message object, and that the EnvelopeFields can
only be accessed in the context of SEO.

> {i'm not claiming it is the only or best method just the first seen
> via a cursory glance a documentation}

You have not found a method that works. It is neither only nor best:
it _does not work_. And the reason you do not know this is that you do
not have experience with the technology at hand.

>>You actually said that familiarity with a library is unimportant to
>>"anyone but the programmer" -- anyone but the programmer who wrote the
>>compiled library? *snicker*
>
> no anyone but the programmer writing the app that utilises the library
> {how is this not obvious!!}

It's not obvious because, um, neither interpretation makes sense.

[1] The library programmer, [2] the systems programmer, *and* [3] the
person who acts like he can help anyone with any library in fact need
to be familiar with the library. Or they screw up. Which you did.

> where do i lie about familiarity, I have installed and
> configured/fixed exchange servers since it was first released. yes i
> never recommend it {but that is simply due to its longstanding
> non-rfc non-BCP behaviour*} but many of my customers run it and I
> administer it for them.

Anyone who has really supported Exchange has heard of CDO: your claim
continues to be flatly unbelievable.

I say again: it's perfectly fine for you to not have heard of CDO, as
it is not RFC-standard SMTP technology: why do you take this truth so
hard that you keep trying to be master of all domains? You seemed to
bow out when you said you aren't a "M$" user, but once I said I would
take it from there, you tried to act like you could have equivalent
success to someone who (a) is a programmer and (b) is not overtly
unfriendly to Microsoft products.

> *even now its incapable of forwarding messages in a way that
> complies with microsoft's own demands on forwarders to comply with sender-id

> I havn't claimed any authority on M$ or CDO, just on SPF and SMTP
> Sender-id etc. I HAVE stated i have never heard of CDO and have no
> need to not being a software programmer

As I said -- it seems so long ago -- you can't believe you are have
the expertise to help someone with using an SMTP library if you (a)
are not a programmer and (b) have never heard of the library.

That's what product-specific experience is for. You can hardly
convince experienced professionals that there is no utility to having
day-one familiarity with actual products, not just RFCs.

> why would anyone want to do that? i worked for MSN for long enough
> to know that i wouldn't ever want to do that

Then stop pretending you can help people with Microsoft technology!

>> That can be very dangerous: you might not care to use tired epithets like 'M$' and 'tecNOT' anymore, and what fun would
>>life be if you couldn't mock somebody's platform choices while claiming you were there to help (for money)?

> sorry but yes i will berate their tech as long as i see it being
> the main PITA for all of the mailsystems of receivers and senders i maintain

I am not denying that the company deserves a measure of mockery.
However, these epithets are so cliché at this point that they seem to
me to indicate platform fascism and willful ignorance more often than
they indicate a mixture of skepticism and skill.

Your performance in not having heard of CDO and not even trying your
would-be solutions does nothing to dispel my intuition in this case.
It may not apply in other forums (for example, when people use the
epithets in support lists for Windows products).

>>Anyway, go get 'em on the use of frames, le tigre. You want me to
>>PayPal you something for your trouble in going to MSDN for two
>>seconds?

> as i said i wish to discontinue this continued personal attacks, i
> find it inappropriate for a supposedly professional forum
> I have not resorted to your level and only responded here due to
> the personal nature of your comments

Hm, your "if help not wanted from those with expertise let them go and
f*ck up however they want" isn't an implicit attack on the person who
has decided to provide help (not to mention an attack on the OP)?

--Sandy



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> From: alan [mailto:spfdiscuss@alandoherty.net]
>> ... just one word of advice don't be like 90% of MTA admins and
>> completely disregard the mandatory need for SPF for your EHLO/HELO
>> greeting ID.
>
> They've probably been disregarding it, because there is NO such mandatory
> need. From RFC 4408:
>
> 2.1. The HELO Identity
>
> It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
> identity, but also separately check the "HELO" identity by applying
> the check_host() function (Section 4) to the "HELO" identity as the
> <sender>.
>
>> if you do you will seem to any of us compliance extremists just to be
>> another spambot as no other SPF checks are considered trusted if
>> HELO/EHLO
>> doesn't pass.
>
> That's an utterly ignorant statement. For all the (loud) grandstanding
> you've been doing for the last few days, perhaps you ought to do well and
> get your own affairs in order first.
>

And for those that don't know Mark was a major contributor to RFC 4408 and
the two years of draft specs that preceded it. Perhaps we could take this
as the final word in this thread?

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

At 22:57 13/05/2009 Wednesday, Mark wrote:
>-----Original Message-----
>From: alan [mailto:spfdiscuss@alandoherty.net]
>Sent: woensdag 13 mei 2009 20:08
>To: spf-discuss@v2.listbox.com
>Subject: Re[10]: [spf-discuss] Trying to understand the best recommendation
>for my client, help appreciated.
>
>> ... just one word of advice don't be like 90% of MTA admins and
>> completely disregard the mandatory need for SPF for your EHLO/HELO
>> greeting ID.
>
>They've probably been disregarding it, because there is NO such mandatory
>need. From RFC 4408:
>
>2.1. The HELO Identity
>
> It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
> identity, but also separately check the "HELO" identity by applying
> the check_host() function (Section 4) to the "HELO" identity as the
> <sender>.
>
>> if you do you will seem to any of us compliance extremists just to be
>> another spambot as no other SPF checks are considered trusted if HELO/EHLO
>> doesn't pass.
>
>That's an utterly ignorant statement. For all the (loud) grandstanding
>you've been doing for the last few days, perhaps you ought to do well and
>get your own affairs in order first.

in deference to your quoting only the part referencing what the client is recommended to check {reciever side}

and because my own domains and MTA's do publish the correct SPF
and on a per user address basis too ie nosuchuser@anyofmydomains will return an spf of "v=spf1 -all"

heres the relevant parts bolding of parts that make HElO publising manditory
{manditory for all {except but servers that never send mail from <>, ie servers that never send NDR's} which are few and far between}

2.2. The MAIL FROM Identity

The "MAIL FROM" identity derives from the SMTP MAIL command (see
[RFC2821]). This command supplies the "reverse-path" for a message,
which generally consists of the sender mailbox, and is the mailbox to
which notification messages are to be sent if there are problems
delivering the message.

[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
RFC 2821). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the
localpart "postmaster" and the "HELO" identity (which may or may not
have been checked separately before).

SPF clients MUST check the "MAIL FROM" identity. SPF clients check
the "MAIL FROM" identity by applying the check_host() function to the
"MAIL FROM" identity as the <sender>.

2.3. Publishing Authorization

An SPF-compliant domain MUST publish a valid SPF record as described
in Section 3. This record authorizes the use of the domain name in
the "HELO" and "MAIL FROM" identities by the MTAs it specifies.

If domain owners choose to publish SPF records, it is RECOMMENDED
that they end in "-all", or redirect to other records that do, so
that a definitive determination of authorization can be made



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

CDO isn't an SMTP library. It's a message object management library that implements a small portion of SMTP.

Please, find me documentation that says otherwise. I'd love to see this.

--
Devin L. Ganger, Sr. Messaging Architect <deving@3sharp.com>
Microsoft Certified Master | Exchange 2007; Exchange MVP
3Sharp LLC                         Phone: 425.882.1032 x1011
14700 NE 95th Suite 210             Cell: 425.239.2575
Redmond, WA  98052                   Fax: 425.702.8455
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/


-----Original Message-----
From: Sanford Whiteman [mailto:sandy@cypressintegrated.com]
Sent: Wednesday, May 13, 2009 3:15 PM
To: alan
Subject: Re[12]: [spf-discuss] Trying to understand the best recommendation for my client, help appreciated.

> if the answer given is wrong explain how the manual indicates it
> the very method to use to set the envelope-sender

*sigh* Among other details, MSDN indicates that the apparent sendemail
property in Configuration.Fields is one of several macros for the
Sender property on the Message object, and that the EnvelopeFields can
only be accessed in the context of SEO.

> {i'm not claiming it is the only or best method just the first seen
> via a cursory glance a documentation}

You have not found a method that works. It is neither only nor best:
it _does not work_. And the reason you do not know this is that you do
not have experience with the technology at hand.

>>You actually said that familiarity with a library is unimportant to
>>"anyone but the programmer" -- anyone but the programmer who wrote the
>>compiled library? *snicker*
>
> no anyone but the programmer writing the app that utilises the library
> {how is this not obvious!!}

It's not obvious because, um, neither interpretation makes sense.

[1] The library programmer, [2] the systems programmer, *and* [3] the
person who acts like he can help anyone with any library in fact need
to be familiar with the library. Or they screw up. Which you did.

> where do i lie about familiarity, I have installed and
> configured/fixed exchange servers since it was first released. yes i
> never recommend it {but that is simply due to its longstanding
> non-rfc non-BCP behaviour*} but many of my customers run it and I
> administer it for them.

Anyone who has really supported Exchange has heard of CDO: your claim
continues to be flatly unbelievable.

I say again: it's perfectly fine for you to not have heard of CDO, as
it is not RFC-standard SMTP technology: why do you take this truth so
hard that you keep trying to be master of all domains? You seemed to
bow out when you said you aren't a "M$" user, but once I said I would
take it from there, you tried to act like you could have equivalent
success to someone who (a) is a programmer and (b) is not overtly
unfriendly to Microsoft products.

> *even now its incapable of forwarding messages in a way that
> complies with microsoft's own demands on forwarders to comply with sender-id

> I havn't claimed any authority on M$ or CDO, just on SPF and SMTP
> Sender-id etc. I HAVE stated i have never heard of CDO and have no
> need to not being a software programmer

As I said -- it seems so long ago -- you can't believe you are have
the expertise to help someone with using an SMTP library if you (a)
are not a programmer and (b) have never heard of the library.

That's what product-specific experience is for. You can hardly
convince experienced professionals that there is no utility to having
day-one familiarity with actual products, not just RFCs.

> why would anyone want to do that? i worked for MSN for long enough
> to know that i wouldn't ever want to do that

Then stop pretending you can help people with Microsoft technology!

>> That can be very dangerous: you might not care to use tired epithets like 'M$' and 'tecNOT' anymore, and what fun would
>>life be if you couldn't mock somebody's platform choices while claiming you were there to help (for money)?

> sorry but yes i will berate their tech as long as i see it being
> the main PITA for all of the mailsystems of receivers and senders i maintain

I am not denying that the company deserves a measure of mockery.
However, these epithets are so cliché at this point that they seem to
me to indicate platform fascism and willful ignorance more often than
they indicate a mixture of skepticism and skill.

Your performance in not having heard of CDO and not even trying your
would-be solutions does nothing to dispel my intuition in this case.
It may not apply in other forums (for example, when people use the
epithets in support lists for Windows products).

>>Anyway, go get 'em on the use of frames, le tigre. You want me to
>>PayPal you something for your trouble in going to MSDN for two
>>seconds?

> as i said i wish to discontinue this continued personal attacks, i
> find it inappropriate for a supposedly professional forum
> I have not resorted to your level and only responded here due to
> the personal nature of your comments

Hm, your "if help not wanted from those with expertise let them go and
f*ck up however they want" isn't an implicit attack on the person who
has decided to provide help (not to mention an attack on the OP)?

--Sandy



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> CDO isn't an SMTP library. It's a message object management library
> that implements a small portion of SMTP.

Is this your new take since your "it's MAPI" nonsense was rebuffed"

CDOSYS is _the_ OS-native way of creating and submitting SMTP and NNTP
objects in unmanaged code. The managed System.Web.Mail namespace is a
simple wrapper for CDOSYS.

Only with System.Net.Mail has CDOSYS been superseded as the preferred,
Windows-native method of managing and transmitting RFC 822 SMTP/MIME
messages.

> Please, find me documentation that says otherwise. I'd love to see
> this.

You'll swoon for

http://msdn.microsoft.com/en-us/library/ms978698.aspx#cdo_roadmap_topic2

"... is is the standard API for building bulk-mailing/Web-based
messaging applications..."

--Sandy





-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> CDO isn't an SMTP library. It's a message object management library
> that implements a small portion of SMTP.

Also, follow along closely, not CDO, but C-D-O-S-Y-S.

It is a commonplace of Classic ASP (unmanaged) development that one
either chooses CDONTS (deprecated after CDOSYS came out), CDOSYS, or a
third-party COM library with extended features when implementing SMTP
client features.

The chosen option is considered "the SMTP client library in use" by
anyone who develops for a living.

--Sandy



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> no other SPF checks are considered trusted if HELO/EHLO doesn't pass

RFC 4408 doesn't state that "no other SPF checks are considered
trusted if HELO/EHLO doesn't pass." Your assertion is instantly
falsified by testing w/the baked-to-order pySPF toolset on the
website.

When using the postmaster@HELO as a synthetic MAIL FROM, there is no
other SPF check to run to be RFC compliant, so there can be no "chain
of trust." Checking both HELO-as-HELO and postmaster@HELO-as-MAIL-FROM
(which will in most cases be redundant) is an option, but also hardly
a "chain of trust."

An edge case in which a PASS on HELO (as opposed to NONE or any other
result on HELO) might be a constant prerequisite when sending to a
given server is if that server has the custom policy "if *any*
checkable part of a given envelope has a published SPF record, then
*all* checkable parts must have published SPF and PASS." Or, of
course, a policy that requires PASS on HELO for every connection,
period. Such policies may be interesting, but beyond RFC.

--Sandy



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

>> no other SPF checks are considered trusted if HELO/EHLO doesn't pass
>
> RFC 4408 doesn't state that "no other SPF checks are considered
> trusted if HELO/EHLO doesn't pass." Your assertion is instantly
> falsified by testing w/the baked-to-order pySPF toolset on the
> website.
>
> When using the postmaster@HELO as a synthetic MAIL FROM, there is no
> other SPF check to run to be RFC compliant, so there can be no "chain
> of trust." Checking both HELO-as-HELO and postmaster@HELO-as-MAIL-FROM
> (which will in most cases be redundant) is an option, but also hardly
> a "chain of trust."
>
> An edge case in which a PASS on HELO (as opposed to NONE or any other
> result on HELO) might be a constant prerequisite when sending to a
> given server is if that server has the custom policy "if *any*
> checkable part of a given envelope has a published SPF record, then
> *all* checkable parts must have published SPF and PASS." Or, of
> course, a policy that requires PASS on HELO for every connection,
> period. Such policies may be interesting, but beyond RFC.
>
This is basically correct. The only connection between Mail From and HELO
checking is substitution of the HELO result if Mail From is null.
Otherwise they are two separate inputs into local policy for
accepting/rejecting mail (RFC 4408 is essentially silent for receiver
policy).

As an example, in
http://www.openspf.org/Software#python-postfix-policyd-spf by default I
first check for HELO and if it has an SPF result of Fail/Softfail/Neutral
return a reject result. I view failing a HELO check as an easy win for
early rejection of mail that's very unlikely to be desired. Then Mail
From is checked and SPF Fail on Mail From is rejected. The remaining
results are included in a header for post-SMTP processing (e.g. used by
Spamassassin).

So while I think your message is technically correct, I think the tone in
this thread continues to be unhelpful (not just you, but including you).

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

At 01:22 14/05/2009 Thursday, Sanford Whiteman wrote:
>> no other SPF checks are considered trusted if HELO/EHLO doesn't pass
>
>RFC 4408 doesn't state that "no other SPF checks are considered
>trusted if HELO/EHLO doesn't pass." Your assertion is instantly
>falsified by testing w/the baked-to-order pySPF toolset on the
>website.

i never meant to imply it was

>An edge case in which a PASS on HELO (as opposed to NONE or any other
>result on HELO) might be a constant prerequisite when sending to a
>given server is if that server has the custom policy "if *any*
>checkable part of a given envelope has a published SPF record, then
>*all* checkable parts must have published SPF and PASS." Or, of
>course, a policy that requires PASS on HELO for every connection,
>period. Such policies may be interesting, but beyond RFC.

i wasn't talking about RFC compliance but simply Best practice

most scoring systems i've seen the internals of, mine included
{i'm only detailing the SPF related ones as the Sender-id and other ones are irrelevant to this list}

positive trust score for FcRDNS checking out {most reject on fail, I negative score}
{means ip is traceable to org but little else}

bigger trust score for FcRDNS+helo-spf-pass {none on no-spf} negative-points on fail-spf
{means IP is running an MTA}

{all tend to do this much} mine offer an extra two currently

yet bigger trust score on FcRDNS+helo-spf-pass+{FcRDN not equal to but same domain as HELO} no effect on fail
{means ip is an MTA and sending application is likely the MTA not another malicious application {on the same machine or NAT'd via same gateway}}

yet bigger trust score on FcRDNS checking out+helo-spf-pass+{FcRDN not equal to but same domain as HELO}+spf for FcRDNS being fail
{means ip is an MTA and sending application is likely the MTA
and admin is consciously blocking malicious application via his SPF record for FcRDNS name}

{as all recent spam-bots will, if they find FcRDNS, use it in their HELO}

{mine does this just to promote the concept of differentiating MTA's from non MTA's}
needless to say i also don't bother doing these extra bits of work till long after the RBL's etc have been used for scoring/blocking}

these checks and many more are added to the spamassain scoring of a message for end of DATA rejects
{also users are allowed to make {RCPT TO:} block decisions based on any datapoint themselves if they want to use their address as a LARTing tool few except the draconian ones do, that said one blocks all except when from and connecting IP matches his own whitelists}




-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> you will seem to any of us compliance extremists just to be another
> spambot as no other SPF checks are considered trusted if HELO/EHLO
> doesn't pass.

> i never meant to imply it was [in RFC 4408]

> i wasn't talking about RFC compliance but simply Best practice

In a newsgroup focused on a pub'd standard, if you don't want readers
to think you're talking about compliance with the standard, you should
use words other than "compliance" to describe your motivation for a
certain configuration.

Maybe "stricter-than-standards anti-abuse architectures" is a fair
wrapper term for your policies, which I don't use judgmentally. "My
server, my rules" thinking and "standards compliance" thinking are
starkly different. Both have their place, but mixing terms from one
with policies from the other is bound to confuse. From looking at the
textual description of your ruleset, it seems well-thought-out and not
egregiously draconian. Still, the rules are local rules that don't fit
the open standards and/or public regulatory meaning of "compliance,"
but rather within the realm of personal/internal policies.

I'm sure there was no way to say this without it adding to the
negative tone, but I can't see a way out of it. I'll add a few
smileys. :)))

--Sandy



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

At 04:51 14/05/2009 Thursday, Sanford Whiteman wrote:
>> you will seem to any of us compliance extremists just to be another
>> spambot as no other SPF checks are considered trusted if HELO/EHLO
>> doesn't pass.
>
>> i never meant to imply it was [in RFC 4408]
>
>> i wasn't talking about RFC compliance but simply Best practice
>
>In a newsgroup focused on a pub'd standard, if you don't want readers
>to think you're talking about compliance with the standard, you should
>use words other than "compliance" to describe your motivation for a
>certain configuration.
>
>Maybe "stricter-than-standards anti-abuse architectures" is a fair
>wrapper term for your policies, which I don't use judgmentally. "My
>server, my rules" thinking and "standards compliance" thinking are
>starkly different. Both have their place, but mixing terms from one
>with policies from the other is bound to confuse. From looking at the
>textual description of your ruleset, it seems well-thought-out and not
>egregiously draconian. Still, the rules are local rules that don't fit
>the open standards and/or public regulatory meaning of "compliance,"
>but rather within the realm of personal/internal policies.
>
>I'm sure there was no way to say this without it adding to the
>negative tone, but I can't see a way out of it. I'll add a few
>smileys. :)))

thank you, honestly for the tone change

I think though any receiver is only ever running in "anti-abuse architecture" mode
i prefer to refer to it as rewarding compliance to Best practices
{as its more geared to raising the trust score for good MTA's than lowering the score for bad}
ie their are many data points you can only score well or nothing on

thus upshot is less>no false positives for those running mail via a very well setup MTA {more customers for them}
and hopefully encouragement for those other senders to adopt Better practices {less customers or more unhappy ones}

ending up in less receiver load {eventually} due to bots being clearly differentiable from badly-admined-MTA's

{think back to before AOL started to refuse mail from those missing FcRDNS, before then it was argued it was only extremists that demanded it, now its considered slightly mad to not do so}




>--Sandy
>
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.org
>Modify Your Subscription: http://www.listbox.com/member/
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/
>Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Sanford Whiteman wrote:

> Is this your new take since your "it's MAPI" nonsense was rebuffed"

Please tone down the vitriol. I confused the specifics of two legacy APIs -- not hard to do when talking about the myriad of APIs Microsoft creates. CDONTS was the one based on MAPI; CDOSYS, as you have pointed out multiple times, is not (although CDOEX adds that back in to provide access to Exchange functionality). There's no need to turn it into a major criminal prosecution. I'll point out that your original snarky "OMG you've never hear of this! LOLs!" message -- the one I replied to -- simply said CDO, not CDOSYS specifically. You did refer to CDOSYS in a separate reply in the thread, but at that time you weren't consistently identifying CDOSYS. There's not yet a Mind-to-Mind Transfer Protocol.

> You'll swoon for
>
> http://msdn.microsoft.com/en-us/library/ms978698.aspx#cdo_roadmap_topic2
>
> "... is is the standard API for building bulk-mailing/Web-based
> messaging applications..."

That's actually not saying what you seem to be asserting it is saying. Out of the box CDOSYS provides limited implementations of SMTP and NNTP client functionality; it is not and was never intended to be a full-fledged SMTP implementation, or even a full SMTP client implementation. CDOSYS was optimized for the types of applications that Microsoft thought it would be most used for -- Web-based ASP applications or simple bulk-mail scripts. Web-based/bulk-mail messaging applications are one specific type of application and many messaging administrators can go through their entire careers without having to ever deal directly with these types of applications they way they have to get familiar with the specific clients their companies roll out.

All that aside, let's get back to your original implication that Alan was somehow less than experienced with SMTP just because he'd not heard of CDO and family. CDOSYS, CDOEX, and the System.Web.Mail wrapper are all client application interfaces and not the actual transport protocol. There's no conceivable reason an Unix mail admin, or heck, even an Exchange admin, have ever really had to deal directly with CDOSYS and know it. I'd expect a mail admin to know SMTP -- but I wouldn't *expect* them to know *any* API that implements some or all of SMTP unless they were also a developer in the appropriate programming languge.

Also for the record, I didn't say that CDO "predates 'SMTP mailers'" -- I specifically said that MAPI (and the original CDO) were designed and written "before SMTP mailers really rose to prominence". CDO 1.0 was introduced with Exchange 4.0 in 1996, back before SMTP had fully won its status as the de facto message transport standard. There were a LOT of other transports in existence and wide usage back then; SMTP was merely one among many. MAPI and the original CDO were intended for full compliance with the more complex X.400 standard, and SMTP messages didn't always map well to CDO (you should have seen some of the interesting test cases that came up with the original Exchange 4.0 and 5.0 SMTP gateways specifically because of the X.400 <-> SMTP interoperability issues). That's part of the reason why CDOSYS was necessary.

That's probably way too long of a way to say, "Dude, administrator vs. developer" -- but that's what it comes down to. I apologize for my contribution to the misunderstanding.

--
Devin L. Ganger, Messaging Architect <deving@3sharp.com>
Exchange MVP, Microsoft Certified Master | Exchange 2007
3Sharp LLC                         Phone: 425.882.1032 x1011
14700 NE 95th Suite 210             Cell: 425.239.2575
Redmond, WA  98052                   Fax: 425.702.8455
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/





-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

> You did refer to CDOSYS in a separate reply in the thread, but at
> that time you weren't consistently identifying CDOSYS.

The archives'll reflect that I used the brand "CDOSYS" in the very
first post in which the product was mentioned. And since CDOSYS is the
only non-deprecated SMTP client library (the old one being CDONTS)
that begins with the letters C-D-O, there could not have been any
doubt to someone who knows the Microsoft programming technologies that
that was the flavor that continued to be under discussion. It is not
obligatory to continuously provide longhand for an off-topic post.
That was why I answered it off-list -- before being summoned back for
a flame war.

There is the very absurdity of this topic again: I remain the only
list member (the only one who responded, at least) who knew what the
OP was talking about. I simply stated that I would "take it from
here." That led to all kinds of arguments (!) about whether
product-specific knowledge might be of assistance to solve the OP's
problem. I rightly took those arguments as directly insulting the
significance of this hard-earned part of my skill set.

> Out of the box CDOSYS provides limited implementations of SMTP and
> NNTP client functionality; it is not and was never intended to be a
> full-fledged SMTP implementation, or even a full SMTP client
> implementation.

CDOSYS is an SMTP client library; there is no difference of opinion on
this point in the world in which CDOSYS is used; this is not your
world as an Exchange admin.

If Microsoft's summary "The CDOSYS library is an implementation of the
Simple Mail Transfer Protocol (SMTP) and the Network News Transfer
Protocol (NNTP)" does not convince you that there is strong vendor
support for this real-world usage, I guess nothing will.

It is a tautology that a complete RFC 821/822 smtp-sender
implementation differs from the feature set of CDOSYS and many other
products nonetheless correctly labeled as SMTP client
libraries/components/APIs. For one example, a full RFC implementation
would include the ability to perform direct DNS-based delivery.
However, the SMTP client libraries used by common MUAs such as Outlook
and Thunderbird are still correctly called SMTP libraries. Likewise a
library used by a mail blaster may support DNS lookups, but not
support as full a list of SMTP AUTH mechanisms as the Microsoft
libraries. It is still an SMTP library.

> All that aside, let's get back to your original implication that
> Alan was somehow less than experienced with SMTP just because he'd
> not heard of CDO and family.

No, that is a deliberate misquote, and the implication was plain: of
the two (later three) people considering an off-topic post in this
newsgroup regarding a well-known vendor's product, I am the one
qualified to answer the question accurately because of my
product-specific knowledge. Attempts to undermine the significance of
deep product-specific knowledge will not fly.

Nothing you have posted contravenes this original implication.

--Sandy



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Can we please end this thread. It's been quite some days since the OP had
any more questions.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

I think thats a good idea, ive ran out of popcorn!

:-)

Andrew


On 15 May 2009, at 15:10, Scott Kitterman wrote:

> Can we please end this thread. It's been quite some days since the
> OP had
> any more questions.
>
> Scott K
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com