Mailing List Archive

first off due to the content of the mail i can only assume you don't actually understand how SMTP / email is transmitted

so it would be better if you addressed these questions via someone involved in writing your software {and thus au fait with SMTP}

simply put the from address is irrelevant to spf
no content within the email at all is relevant to spf

spf does not read or look at any part of the email or headers

"Bounced emails and non-delivery reports, which are a crucial part of the service they provide, are sent back to clients system, not the person who they are sending on behalf of, and are analysed by the tool for reporting. This is currently done using return-path headers in the email generation process"
- is simply untrue

bounce emails are sent to the <envelope-from> address {not anything within the email or headers}
in fact the "return-path" header dosn't exist in the email in transit {if it is there its a big spam/forgery/replay sign}
it only added by the end receivers email system to record what the <envelope-from> was, once the email arrives before the envelope data is dumped

spf only validates
the <envelope-from> of the email in transit
and
the HELO/EHLO identity of the server connecting to the receiver

any other use of SPF records or data is mis-use

microsoft sender-id on the other hand defines policy for

{mfrom} == <envelope-from>
and
purported responsible sender {pra} == From: {the one they see on the mail}

and it will if not seeing explicit sender-id records, mis-use the SPF records to try to {in}validate the From: line

but this is simply addressed by the customer publishing explicit sender-id records either allowing the pra from everywhere
{ie don't fail me due to sender-id ever}
or just their and your range
{if deciding to try and play ball with the broken sender-id protocol, this will cause them pain if using any mailinglists or even srs forwarding, why most go for the former route}

feel free to look at my spf/sender-id/etc records to see difference




At 22:41 11/05/2009 Monday, Ben Gallienne wrote:
>Hi All,
>
>I hope you can help me. I have been contracted to maintain and develop a bulk email generation tool for one of my clients. Under their current system, which passes SPF, emails are received from their system showing the from address as ?someone@client.com? on behalf of ?someone@clientscustomer.com?. Bounced emails and non-delivery reports, which are a crucial part of the service they provide, are sent back to clients system, not the person who they are sending on behalf of, and are analysed by the tool for reporting. This is currently done using return-path headers in the email generation process.
>
>The client have recently been getting customers ask for the ability to have the from address simply read ?someone@clientscustomer.com?, and also have this be the reply-to address, but at the same time retain the functionality that returns the bounced emails and non-delivery reports to the tool address ?someone@client.com?. I have tried numerous combinations to achieve this and get a passed SPF result, but cannot seem to find out the correct way to do it. It seems in order to get a pass in SPF and no ?on behalf of? message, the sender property must equal the from property, but this means the bounces are sent to the customer, not to the tool. If the sender is different, the bounced emails go to the right place, but the ?on behalf of? appears again.
>
>My question therefore is have I missed the correct combination? Or can it simply not be done and pass SPF as well? My client?s customer, understandably, wants their recipients to see that the mail has come from them, but still want the functionality offered by the tools non-delivery functions. And my client wants to deliver emails that are correctly not considered as spam.
>
>Can anyone help point in the right direction please? Any help or assistance that can be offered would be greatly appreciated.
>
>Thanks in advance for your help,
>
>Ben
>
>----------
>Sender Policy Framework: <http://www.openspf.org>http://www.openspf.org
>Modify Your Subscription: <http://www.listbox.com/member/>http://www.listbox.com/member/
><https://www.listbox.com/member/archive/735/=now>Archives<https://www.listbox.com/member/archive/rss/735/>



-------------------------------------------
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

> Under their current system, which passes SPF, emails are received
> from their system showing the from address as 'someone@client.com'
> on behalf of 'someone@clientscustomer.com'.

This "showing" is unique to certain Microsoft MUAs. I am not denying
that Outlook is in massive use, but you should be aware that this part
of your problem is not as general as you think.

Outlook does this based on a mismatch between the Sender: and From:
headers. It has nothing to do -- as far as the mailreader is concerned
-- with the envelope sender.

> This is currently done using return-path headers in the email
> generation process.

As Alan pointed out, it is not the R-P doing the work, but the
envelope sender (MAIL FROM) that dictates where bounces go. The R-P
happens to reflect the envelope sender when the message is removed
from the SMTP stream; any intermediate R-P is untrustworthy and not
actionable. It is very rare that any mail processing needs to be based
on the R-P; it would only be actionable in a specific setup where it
was known to have been applied at a trusted hop *and* the envelope
sender is not persisted in any other way.

Or, to re-simplify for your case, bounces don't go to the R-P, they go
to the MAIL FROM.

> If the sender is different, the bounced emails go to the right
> place, but the 'on behalf of' appears again.

What you are confusing is the Sender: _header_ and the envelope
sender. Outlook wants the Sender: and the From: to match. It doesn't
care about the envelope sender. So in theory, it is quite simple to
craft messages that do what you want, say using Telnet! BUT the rub is
that many primitive SMTP libraries -- I don't know which one you are
using, but you should divulge it if you want specific help -- DO
confuse header (RFC x822) and envelope (RFC x821) information. They do
this to make things "easier" for developers. But they end up
hard-coding relationships that have no legitimate RFC link.

For example, they may let you supply arguments for what they call
'From', optional 'Reply-To', and an optional 'Sender'. If you just
give it the 'From', they map this to the From: header and
(erroneously/silently/misleadingly) to the envelope sender. If you
give it the 'From' and the 'Sender', then the 'From' only appears in
the header, but the 'Sender' goes into the Sender: header _and_ is
used as the envelope sender.

Unless they break out all the envelope and header fields in an
RFC-accurate fashion (daring to "confuse" the developer by actually
laying out the way mail bodies, headers, and envelopes work!), it can
be impossible to do what you want with your current SMTP client
library. However, it is completely, and simply, possible to do with a
good SMTP library.

--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

Hi Sandy, Alan,

Thanks very much for your helpful replies. It seems that as you rightly say
I have got some things confused as a developer. I haven't coded for a system
that sends mail this way before so I may be asking some dumb questions for
which I apologise, but be assured your help is much appreciated.

I will certainly inform the client about the 'on behalf of' issue and it's
unique-ness to Outlook and certain Microsoft MUAs, that's a really useful
piece of information so thanks very much for that. If there is a way that I
can offer them a solution though that would be excellent, and I get the
impression from the rest of your mail that there may well be, so here's how
the system currently works.

Mails are sent using the classic asp server object 'cdo.message'. The
current system populates the following properties of each message (called
messageObject here):

messageObject.Fields("urn:schemas:mailheader:sender") = 'bounce address'
messageObject.From = 'client customer address'
messageObject.ReplyTo = 'bounce address'

This currently creates the scenario I described. Emails appear (in Outlook)
to have come from 'bounce address' on behalf of 'client customer address',
and non-delivery reports go to the 'bounce address'. When people click reply
then the address in the To field is 'bounce address'.

The replyto problem is obviously a simple code change so that it is set to
'client customer address', and solves that problem so that's fine. It's then
just a question of finding a way that the sender can match the from address
and therefore remove the 'on behalf of' statement in the offending Microsoft
MUAs, yet still return non-delivery reports to the 'bounce address'. I think
this is where my confusion has come from regarding return-paths. I did some
investigating and the other properties I found that can be set the
cdo.message object in classic asp (there may be more) are:

messageObject.Sender - I don't know if this is actually the same as setting
the urn:schemas:mailheader:sender or not, the documentation is not explicit

messageObject.Fields("urn:schemas:mailheader:return-path") - I think this is
where the confusion has arisen, and perhaps I shouldn't be using it as it
might be untrustworthy from reading your reply?

And it is at this point that I got stuck and wrote my earlier question. I
think I understand from your comments that what I want to find is if there
is a combination of properties that sets the envelope sender to the 'bounce
address', and the sender and the from to be the 'client customer address',
which I think would achieve my goal. Is this correct in your opinion?

If so, any idea using this language and library what the correct combination
of properties I need is please? I'll obviously keep looking in the meantime
but you might be able to save me some time so as before any help is much
appreciated.

I also appreciate now from reading both your mails that this has little to
do with passing SPF, so thanks for the education on the front as well.

As before, thanks in advance for your help.

Ben

-----Original Message-----
From: Sanford Whiteman [mailto:sandy@cypressintegrated.com]
Sent: 12 May 2009 04:32
To: Ben Gallienne
Subject: Re: [spf-discuss] Trying to understand the best recommendation for
my client, help appreciated.

> Under their current system, which passes SPF, emails are received
> from their system showing the from address as 'someone@client.com'
> on behalf of 'someone@clientscustomer.com'.

This "showing" is unique to certain Microsoft MUAs. I am not denying
that Outlook is in massive use, but you should be aware that this part
of your problem is not as general as you think.

Outlook does this based on a mismatch between the Sender: and From:
headers. It has nothing to do -- as far as the mailreader is concerned
-- with the envelope sender.

> This is currently done using return-path headers in the email
> generation process.

As Alan pointed out, it is not the R-P doing the work, but the
envelope sender (MAIL FROM) that dictates where bounces go. The R-P
happens to reflect the envelope sender when the message is removed
from the SMTP stream; any intermediate R-P is untrustworthy and not
actionable. It is very rare that any mail processing needs to be based
on the R-P; it would only be actionable in a specific setup where it
was known to have been applied at a trusted hop *and* the envelope
sender is not persisted in any other way.

Or, to re-simplify for your case, bounces don't go to the R-P, they go
to the MAIL FROM.

> If the sender is different, the bounced emails go to the right
> place, but the 'on behalf of' appears again.

What you are confusing is the Sender: _header_ and the envelope
sender. Outlook wants the Sender: and the From: to match. It doesn't
care about the envelope sender. So in theory, it is quite simple to
craft messages that do what you want, say using Telnet! BUT the rub is
that many primitive SMTP libraries -- I don't know which one you are
using, but you should divulge it if you want specific help -- DO
confuse header (RFC x822) and envelope (RFC x821) information. They do
this to make things "easier" for developers. But they end up
hard-coding relationships that have no legitimate RFC link.

For example, they may let you supply arguments for what they call
'From', optional 'Reply-To', and an optional 'Sender'. If you just
give it the 'From', they map this to the From: header and
(erroneously/silently/misleadingly) to the envelope sender. If you
give it the 'From' and the 'Sender', then the 'From' only appears in
the header, but the 'Sender' goes into the Sender: header _and_ is
used as the envelope sender.

Unless they break out all the envelope and header fields in an
RFC-accurate fashion (daring to "confuse" the developer by actually
laying out the way mail bodies, headers, and envelopes work!), it can
be impossible to do what you want with your current SMTP client
library. However, it is completely, and simply, possible to do with a
good SMTP library.

--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

On Tue, May 12, 2009 at 3:42 AM, Ben Gallienne <ben@webpoint0.com> wrote:
> Hi Sandy, Alan,
>
> Thanks very much for your helpful replies. It seems that as you rightly say
> I have got some things confused as a developer. I haven't coded for a system
> that sends mail this way before so I may be asking some dumb questions for
> which I apologise, but be assured your help is much appreciated.
>

Ben,

There is another approach your client (it sounds like they are an ESP)
can take. If your clients customers delegate a subdomain to your
client then outbound mail will pass SPF (your client will then manage
the SPF records) and the outbound mail will appear to the recipients
as coming from your clients customers. Your client can use the reply
to field to have replies go directly to customers or they can forward
them using an alias on their inbound mail servers.

This also positions your client nicely for doing DKIM signing as a
first aprty signer rather than a 3rd party signer (a consideration for
ADSP).

Hope this helps.


-------------------------------------------
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 08:42 12/05/2009 Tuesday, Ben Gallienne wrote:
>Hi Sandy, Alan,
>
>Thanks very much for your helpful replies. It seems that as you rightly say
>I have got some things confused as a developer. I haven't coded for a system
>that sends mail this way before so I may be asking some dumb questions for
>which I apologise, but be assured your help is much appreciated.
>
>I will certainly inform the client about the 'on behalf of' issue and it's
>unique-ness to Outlook and certain Microsoft MUAs, that's a really useful
>piece of information so thanks very much for that. If there is a way that I
>can offer them a solution though that would be excellent, and I get the
>impression from the rest of your mail that there may well be, so here's how
>the system currently works.
>
>Mails are sent using the classic asp server object 'cdo.message'. The
>current system populates the following properties of each message (called
>messageObject here):
>
>messageObject.Fields("urn:schemas:mailheader:sender") = 'bounce address'
>messageObject.From = 'client customer address'
>messageObject.ReplyTo = 'bounce address'
>
>This currently creates the scenario I described. Emails appear (in Outlook)
>to have come from 'bounce address' on behalf of 'client customer address',
>and non-delivery reports go to the 'bounce address'. When people click reply
>then the address in the To field is 'bounce address'.
>
>The replyto problem is obviously a simple code change so that it is set to
>'client customer address', and solves that problem so that's fine. It's then
>just a question of finding a way that the sender can match the from address
>and therefore remove the 'on behalf of' statement in the offending Microsoft
>MUAs, yet still return non-delivery reports to the 'bounce address'. I think
>this is where my confusion has come from regarding return-paths. I did some
>investigating and the other properties I found that can be set the
>cdo.message object in classic asp (there may be more) are:
>
>messageObject.Sender - I don't know if this is actually the same as setting
>the urn:schemas:mailheader:sender or not, the documentation is not explicit
>
>messageObject.Fields("urn:schemas:mailheader:return-path") - I think this is
>where the confusion has arisen, and perhaps I shouldn't be using it as it
>might be untrustworthy from reading your reply?
>
>And it is at this point that I got stuck and wrote my earlier question. I
>think I understand from your comments that what I want to find is if there
>is a combination of properties that sets the envelope sender to the 'bounce
>address', and the sender and the from to be the 'client customer address',
>which I think would achieve my goal. Is this correct in your opinion?

i would say you need to find the option for envelope-sender == bounce
and from: client address

reply-to & sender are unnecessary
{reply to is only set if the replys are to be directed to a different address to the from}
{sender equally is only set if the original mail has been re-sent in transit ie from==original sender sender=re-sender if it has been through a sender-id compliant forwarder}

by setting sender it makes outlook do its "sent by "sender" on behalf of "from" crud

just ensure that the client address if they publish an SPF record also publishes a sender-id-pra that allows the from: in mails from your ip(s) {or better from anywhere}

{as the sender: header was re-purpoused to get round cases where from: address would be denied by sender-id as when it exists it is checked against sender-id instead of from: as the mail is assumed to be "forwarded by "sender" on behalf of "from"}

but as the intricacies of sender-id {and the conflicts with SPF} arn't really relevant on-list feel free to contact me directly to flesh it all out with some real examples and sample records etc.

{for some time I've been meaning to do a SPF faq/setup guide that also shows how/why etc to do it in a way that makes sure no sender-id conflicts happen as both camps steer too clear of one another thus leave users with conflicting or incompatible records}

{hell I'll even offer my time to do the legwork and advise you/your customers about all spf/sender-id stuff as a consultant if your interested in off-loading it all}


>If so, any idea using this language and library what the correct combination
>of properties I need is please? I'll obviously keep looking in the meantime
>but you might be able to save me some time so as before any help is much
>appreciated.

point me at a url for the library manual?


>I also appreciate now from reading both your mails that this has little to
>do with passing SPF, so thanks for the education on the front as well.
>
>As before, thanks in advance for your help.
>
>Ben
>
>-----Original Message-----
>From: Sanford Whiteman [mailto:sandy@cypressintegrated.com]
>Sent: 12 May 2009 04:32
>To: Ben Gallienne
>Subject: Re: [spf-discuss] Trying to understand the best recommendation for
>my client, help appreciated.
>
>> Under their current system, which passes SPF, emails are received
>> from their system showing the from address as 'someone@client.com'
>> on behalf of 'someone@clientscustomer.com'.
>
>This "showing" is unique to certain Microsoft MUAs. I am not denying
>that Outlook is in massive use, but you should be aware that this part
>of your problem is not as general as you think.
>
>Outlook does this based on a mismatch between the Sender: and From:
>headers. It has nothing to do -- as far as the mailreader is concerned
>-- with the envelope sender.
>
>> This is currently done using return-path headers in the email
>> generation process.
>
>As Alan pointed out, it is not the R-P doing the work, but the
>envelope sender (MAIL FROM) that dictates where bounces go. The R-P
>happens to reflect the envelope sender when the message is removed
>from the SMTP stream; any intermediate R-P is untrustworthy and not
>actionable. It is very rare that any mail processing needs to be based
>on the R-P; it would only be actionable in a specific setup where it
>was known to have been applied at a trusted hop *and* the envelope
>sender is not persisted in any other way.
>
>Or, to re-simplify for your case, bounces don't go to the R-P, they go
>to the MAIL FROM.
>
>> If the sender is different, the bounced emails go to the right
>> place, but the 'on behalf of' appears again.
>
>What you are confusing is the Sender: _header_ and the envelope
>sender. Outlook wants the Sender: and the From: to match. It doesn't
>care about the envelope sender. So in theory, it is quite simple to
>craft messages that do what you want, say using Telnet! BUT the rub is
>that many primitive SMTP libraries -- I don't know which one you are
>using, but you should divulge it if you want specific help -- DO
>confuse header (RFC x822) and envelope (RFC x821) information. They do
>this to make things "easier" for developers. But they end up
>hard-coding relationships that have no legitimate RFC link.
>
>For example, they may let you supply arguments for what they call
>'From', optional 'Reply-To', and an optional 'Sender'. If you just
>give it the 'From', they map this to the From: header and
>(erroneously/silently/misleadingly) to the envelope sender. If you
>give it the 'From' and the 'Sender', then the 'From' only appears in
>the header, but the 'Sender' goes into the Sender: header _and_ is
>used as the envelope sender.
>
>Unless they break out all the envelope and header fields in an
>RFC-accurate fashion (daring to "confuse" the developer by actually
>laying out the way mail bodies, headers, and envelopes work!), it can
>be impossible to do what you want with your current SMTP client
>library. However, it is completely, and simply, possible to do with a
>good SMTP library.
>
>--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



-------------------------------------------
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

> point me at a url for the library manual?

It is Microsoft CDOSYS.

--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 20:31 12/05/2009 Tuesday, Sanford Whiteman wrote:
>> point me at a url for the library manual?
>
>It is Microsoft CDOSYS.
>
>--Sandy

not a m$ user or having a clue where/what that means, if he dosn't have a url i don't have time to grep the internet looking for it





>-------------------------------------------
>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

> not a m$ user or having a clue where/what that means, if he dosn't
> have a url i don't have time to grep the internet looking for it

That's fine, you should probably leave it to someone who is more
comfortable working with Windows' built-in features.

I will take it from here with 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

At 00:15 13/05/2009 Wednesday, Sanford Whiteman wrote:
>> not a m$ user or having a clue where/what that means, if he dosn't
>> have a url i don't have time to grep the internet looking for it
>
>That's fine, you should probably leave it to someone who is more
>comfortable working with Windows' built-in features.
>
>I will take it from here with the OP.

why smtp is smtp,
I have been admiring diagnosing and fixing mailservers {including exchange} in customer sites ISP's and ESP's for years,

you don't get good at it by ever getting familiar with the os/s they run on,
you only get good by ensuring they all act the same in all conditions

so if you could send the uri it would take only a few mins to point out the functions you need, one library is much like any other
it either has the functions or doesn't, if it doesn't I'll be able to tell that from the manual to.

Its just I don't have the time/inclination to fish through the crap tecNOT interface when you could just email the link directly

{simple minimising the redundant expenditure of effort}


>--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

> I have been admiring diagnosing and fixing mailservers {including
> exchange} in customer sites ISP's and ESP's for years

And you never heard of CDO, a basic building block of Windows,
Exchange and IIS SMTP from Windows NT through 2K3?

Like I said, I'll take care of it. From each according to his ability,
as they say.

--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

I don't think that you meant to come across as condescending as you just did, so let me attempt to smooth ruffled feathers by pointing out that a) there are a LOT of non-Microsoft mailer systems out there, b) Microsoft's adherence to RFCs is somewhat late in the game, c) CDO has nothing directly to do with SMTP and everything to do with MAPI, and d) MAPI was designed and coded before SMTP mailers really rose to prominence. As a result, it's perfectly reasonable that someone is an expert with SMTP systems does not know anything about (or heard of) CDO.

--
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: Tuesday, May 12, 2009 5:28 PM
To: alan
Subject: Re[4]: [spf-discuss] Trying to understand the best recommendation for my client, help appreciated.

> I have been admiring diagnosing and fixing mailservers {including
> exchange} in customer sites ISP's and ESP's for years

And you never heard of CDO, a basic building block of Windows,
Exchange and IIS SMTP from Windows NT through 2K3?

Like I said, I'll take care of it. From each according to his ability,
as they say.

--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

> c) CDO has nothing directly to do with SMTP and everything to do
> with MAPI

You don't know what CDOSYS is, either.

This is fine, people. You don't have to know what it is. Just don't
act like there's no advantage to _already understanding the technology
the OP is using_.

> d) MAPI was designed and coded before SMTP mailers really rose to
> prominence.

I hope you don't actually stand behind the claim that CDO (you are
probably referring to CDONTS, since you haven't heard of CDOSYS)
predates "SMTP mailers".

> As a result, it's perfectly reasonable that someone is an expert
> with SMTP systems does not know anything about (or heard of) CDO.

No one who has real experience with Exchange can not have _heard of_
CDO.

--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

Let's call a halt to measuring who's knowledge of what is bigger and focus
on answering the original question.

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

> Let's call a halt to measuring who's knowledge of what is bigger and
> focus on answering the original question.

Good idea. I am answering it off-list.

--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 03:14 13/05/2009 Wednesday, Sanford Whiteman wrote:
>> Let's call a halt to measuring who's knowledge of what is bigger and
>> focus on answering the original question.
>
>Good idea. I am answering it off-list.

my view sod it! if help not wanted from those with expertise let them go and f*ck up however they want

as to the libraries and OS/programming details

no, familiarity is unimportant to anyone but the programmer

a good programming team {i have been involved in many} has a protocol expert assist to ensure protocol/BCP adherence
I just needed the api details /manual {but as i say if their to lazy to post the uri, why should we bother}
to see if it can do the job and if it can advise on all the points where they may /not adhere if not explicitly specifying values

in your case the datapoints without seeing the manual are

if you had bothered i could have told you where they are specified

IP{s} ensuring its has FcRDNS, ensuring FcRDNS has SPF-deny and csv-deny so trojans and malware can't degrade the reputation of the mailer
helo/ehlo ensuring it adheres to RFC , has SPF, has CSV, points at all IP(s) above, and in BCP is not==FcRDNS but is on same domain
mail from: <envelope sender> ensuring adheres to RFC ,it has SPF for IP(s) above}, has MX's, is read/handled correctly

and in the mail
date: ensuring adheres to RFC
message-id: ensuring adheres to RFC
from: ensuring adheres to RFC , has sender-id, passes dkim/domainkeys if domain has these, has MX's, is read/handled correctly
{and if issues with sender-id, dkim/domainkeys ensure sender: or other workarounds are employed}

and any other as required by content being sent and origin {ie if web mail a received: header showing protocol as http and originating ip and via for any proxies}



-------------------------------------------
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

Alan,

I did send you a mail yesterday containing the links to the documentation
that I have. Maybe you didn't get it so it's copied below for reference.

Mail read:
"
Hi Alan,

Thanks for coming back to me again. I've done some searching around again
this morning and have been unable to find the relevant property that allows
me to set the envelope sender when generating an email using the cdo.message
in vbscript. I've been trying to find the answer in the msdn library
documentation for it so by all means if you're prepared to have a look then
it would be much appreciated. A URL to start with would be
http://msdn.microsoft.com/en-us/library/ms526311(EXCHG.10).aspx , but there
is lots of documentation there. The closest thing I have found to the answer
is on this page,
http://msdn.microsoft.com/en-us/library/ms526283(EXCHG.10).aspx but it seems
to suggest the field is read-only and I can't seem to find anything about
how it might get set programatically.

Thanks again for your help,

Ben
"

As it stands Sandy has kindly provided me with a suggested resolution to the
issue that I'm going to be testing out over the next couple of days with the
client, so I'm happy for this thread to now be closed, and thank you all of
you for your assistance, it's much appreciated.

Thanks,

Ben


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

At 03:14 13/05/2009 Wednesday, Sanford Whiteman wrote:
>> Let's call a halt to measuring who's knowledge of what is bigger and
>> focus on answering the original question.
>
>Good idea. I am answering it off-list.

my view sod it! if help not wanted from those with expertise let them go and
f*ck up however they want

as to the libraries and OS/programming details

no, familiarity is unimportant to anyone but the programmer

a good programming team {i have been involved in many} has a protocol expert
assist to ensure protocol/BCP adherence
I just needed the api details /manual {but as i say if their to lazy to post
the uri, why should we bother}
to see if it can do the job and if it can advise on all the points where
they may /not adhere if not explicitly specifying values

in your case the datapoints without seeing the manual are

if you had bothered i could have told you where they are specified

IP{s} ensuring its has FcRDNS, ensuring FcRDNS has SPF-deny and csv-deny so
trojans and malware can't degrade the reputation of the mailer
helo/ehlo ensuring it adheres to RFC , has SPF, has CSV, points at all IP(s)
above, and in BCP is not==FcRDNS but is on same domain
mail from: <envelope sender> ensuring adheres to RFC ,it has SPF for IP(s)
above}, has MX's, is read/handled correctly

and in the mail
date: ensuring adheres to RFC
message-id: ensuring adheres to RFC
from: ensuring adheres to RFC , has sender-id, passes dkim/domainkeys if
domain has these, has MX's, is read/handled correctly
{and if issues with sender-id, dkim/domainkeys ensure sender: or other
workarounds are employed}

and any other as required by content being sent and origin {ie if web mail a
received: header showing protocol as http and originating ip and via for any
proxies}



-------------------------------------------
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

At 13:30 13/05/2009 Wednesday, Ben Gallienne wrote:
>Alan,
>
>I did send you a mail yesterday containing the links to the documentation
>that I have. Maybe you didn't get it so it's copied below for reference.

yup nothing came thru the list and nothing in my own emal


>Mail read:
>"
>Hi Alan,
>
>Thanks for coming back to me again. I've done some searching around again
>this morning and have been unable to find the relevant property that allows
>me to set the envelope sender when generating an email using the cdo.message
>in vbscript. I've been trying to find the answer in the msdn library
>documentation for it so by all means if you're prepared to have a look then
>it would be much appreciated. A URL to start with would be
>http://msdn.microsoft.com/en-us/library/ms526311(EXCHG.10).aspx , but there
>is lots of documentation there. The closest thing I have found to the answer
>is on this page,
>http://msdn.microsoft.com/en-us/library/ms526283(EXCHG.10).aspx but it seems
>to suggest the field is read-only and I can't seem to find anything about
>how it might get set programatically.
>
>Thanks again for your help,
>
>Ben
>"
>
>As it stands Sandy has kindly provided me with a suggested resolution to the
>issue that I'm going to be testing out over the next couple of days with the
>client, so I'm happy for this thread to now be closed, and thank you all of
>you for your assistance, it's much appreciated.

well for the record it seems to be here
http://msdn.microsoft.com/en-us/library/ms527274(EXCHG.10).aspx
under
IConfiguration Interface {which means you submit the messages via smtp not locally, though the smtp server can be 127.0.0.1:25}

sendemailaddress
"MySelf" <example@example.com>

as otherwise your just dumping mails in a queue dir and letting the smtp server find them and essentially make up the envelope-sender
{which it apparently does by taking the sender: header and mis-using it} thus all the issues

but nice to know this is why so much bad sending practice from IIS hosted sellers, its not their fault its the default in their tools




>Thanks,
>
>Ben
>
>
>-----Original Message-----
>From: alan [mailto:spfdiscuss@alandoherty.net]
>Sent: 13 May 2009 12:11
>To: spf-discuss@v2.listbox.com
>Subject: Re[8]: [spf-discuss] Trying to understand the best recommendation
>for my client, help appreciated.
>
>At 03:14 13/05/2009 Wednesday, Sanford Whiteman wrote:
>>> Let's call a halt to measuring who's knowledge of what is bigger and
>>> focus on answering the original question.
>>
>>Good idea. I am answering it off-list.
>
>my view sod it! if help not wanted from those with expertise let them go and
>f*ck up however they want
>
>as to the libraries and OS/programming details
>
>no, familiarity is unimportant to anyone but the programmer
>
>a good programming team {i have been involved in many} has a protocol expert
>assist to ensure protocol/BCP adherence
>I just needed the api details /manual {but as i say if their to lazy to post
>the uri, why should we bother}
>to see if it can do the job and if it can advise on all the points where
>they may /not adhere if not explicitly specifying values
>
>in your case the datapoints without seeing the manual are
>
>if you had bothered i could have told you where they are specified
>
>IP{s} ensuring its has FcRDNS, ensuring FcRDNS has SPF-deny and csv-deny so
>trojans and malware can't degrade the reputation of the mailer
>helo/ehlo ensuring it adheres to RFC , has SPF, has CSV, points at all IP(s)
>above, and in BCP is not==FcRDNS but is on same domain
>mail from: <envelope sender> ensuring adheres to RFC ,it has SPF for IP(s)
>above}, has MX's, is read/handled correctly
>
>and in the mail
>date: ensuring adheres to RFC
>message-id: ensuring adheres to RFC
>from: ensuring adheres to RFC , has sender-id, passes dkim/domainkeys if
>domain has these, has MX's, is read/handled correctly
>{and if issues with sender-id, dkim/domainkeys ensure sender: or other
>workarounds are employed}
>
>and any other as required by content being sent and origin {ie if web mail a
>received: header showing protocol as http and originating ip and via for any
>proxies}
>
>
>
>-------------------------------------------
>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



-------------------------------------------
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

> as otherwise your just dumping mails in a queue dir and letting the
> smtp server find them and essentially make up the envelope-sender
> {which it apparently does by taking the sender: header and mis-using
> it} thus all the issues

> but nice to know this is why so much bad sending practice from IIS
> hosted sellers, its not their fault its the default in their tools




>>Thanks,
>>
>>Ben
>>
>>
>>-----Original Message-----
>>From: alan [mailto:spfdiscuss@alandoherty.net]
>>Sent: 13 May 2009 12:11
>>To: spf-discuss@v2.listbox.com
>>Subject: Re[8]: [spf-discuss] Trying to understand the best recommendation
>>for my client, help appreciated.
>>
>>At 03:14 13/05/2009 Wednesday, Sanford Whiteman wrote:
>>>> Let's call a halt to measuring who's knowledge of what is bigger and
>>>> focus on answering the original question.
>>>
>>>Good idea. I am answering it off-list.
>>
>>my view sod it! if help not wanted from those with expertise let them go and
>>f*ck up however they want
>>
>>as to the libraries and OS/programming details
>>
>>no, familiarity is unimportant to anyone but the programmer
>>
>>a good programming team {i have been involved in many} has a protocol expert
>>assist to ensure protocol/BCP adherence
>>I just needed the api details /manual {but as i say if their to lazy to post
>>the uri, why should we bother}
>>to see if it can do the job and if it can advise on all the points where
>>they may /not adhere if not explicitly specifying values
>>
>>in your case the datapoints without seeing the manual are
>>
>>if you had bothered i could have told you where they are specified
>>
>>IP{s} ensuring its has FcRDNS, ensuring FcRDNS has SPF-deny and csv-deny so
>>trojans and malware can't degrade the reputation of the mailer
>>helo/ehlo ensuring it adheres to RFC , has SPF, has CSV, points at all IP(s)
>>above, and in BCP is not==FcRDNS but is on same domain
>>mail from: <envelope sender> ensuring adheres to RFC ,it has SPF for IP(s)
>>above}, has MX's, is read/handled correctly
>>
>>and in the mail
>>date: ensuring adheres to RFC
>>message-id: ensuring adheres to RFC
>>from: ensuring adheres to RFC , has sender-id, passes dkim/domainkeys if
>>domain has these, has MX's, is read/handled correctly
>>{and if issues with sender-id, dkim/domainkeys ensure sender: or other
>>workarounds are employed}
>>
>>and any other as required by content being sent and origin {ie if web mail a
>>received: header showing protocol as http and originating ip and via for any
>>proxies}
>>
>>
>>
>>-------------------------------------------
>>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



> -------------------------------------------
> 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

> ------------------------------------------------------------
> Mail was checked for spam by the Freeware Edition of No Spam Today!
> The Freeware Edition is free for personal and non-commercial use.
> You can remove this notice by purchasing a full licens



--
Best regards,
Sanford mailto:sandy@cypressintegrated.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

> as otherwise your just dumping mails in a queue dir and letting the
> smtp server find them and essentially make up the envelope-sender
> {which it apparently does by taking the sender: header and mis-using
> it} thus all the issues

FUD/wrong.

--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 17:45 13/05/2009 Wednesday, Sanford Whiteman wrote:
>> as otherwise your just dumping mails in a queue dir and letting the
>> smtp server find them and essentially make up the envelope-sender
>> {which it apparently does by taking the sender: header and mis-using
>> it} thus all the issues
>
>FUD/wrong.

i'm just going by what it describes in the manual
if its FUD its m$ authored FUD {though can't see how it would cause any Fear {uncertainty and doubt maybe}}

actually though it seems it might be the x-sender header according to the page here
"The recipientlist and senderemailaddress envelope fields and the various message header fields such as (urn:schemas:mailheader:) To, From, Cc, and Bcc are different attributes of the message. The SMTP does not use the mail header fields to route the message; it routes the message based upon the RCPT TO and MAIL FROM protocol commands if a message is submitted using the SMTP, or the x-receiver and x-sender headers if a message is submitted to the local SMTP pickup directory. The envelope fields are not transmitted or stored with the message and exist only for the message's lifetime in SMTP transport."

but i can't find the original page i quoted from originally ATM as i wasn't expecting to have to guide another to what M$ claim in their own documentation

{I really don't care how the library does/dosn't do it i was just quoting/summarising the manual, if it differs from the manual IRL it wouldn't be anything new}

interestingly i find you can't direct link to any of the manual as its all within frames has no one told them about BCP's and how frames are bad for this very reason

>--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

At 17:45 13/05/2009 Wednesday, Sanford Whiteman wrote:
>> as otherwise your just dumping mails in a queue dir and letting the
>> smtp server find them and essentially make up the envelope-sender
>> {which it apparently does by taking the sender: header and mis-using
>> it} thus all the issues
>
>FUD/wrong.

BTW
I'm out and won't be replying to this trolls followups
Ben i will continue to contribute if you have any follow up concerns or need test subjects /material for the SPF sender-ID or DKIM stuff

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

join the 10% that are obviously bothering to distinguish themselves from the rest

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

interestingly this listserv is needless to say in the 90% group ;)


>--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

> I'm out and won't be replying to this trolls followups

Interesting redefinition of the term "troll" from someone striving so
hard to try to get a paid consulting gig through this mailing list.
This isn't a marketplace, kid. If you don't know how to help someone
with the problem that is actually at hand, drop out.

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* Then you gave a completely wrong answer
about CDOSYS, after lying about having familiarity with Exchange. Was
it that you had too much familiarity to give the right answer? Then
you gave another completely wrong answer after doing more "research"
in Microsoft's documentation. I guess you're just too deep inside at
this point.

Perish the thought that you might actually have tried the technology
first before answering with any degree of authority. Hmm, but then you
would have actually spent uncompensated time helping someone out.
Worse, you might have accidentally achieved some expertise in a
Windows 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)?

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?

--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

CDONT replaced by CDOSYS is black box and provide only basic SMTP functions,
and only one way to do what you need is MAYBE to write directly to header
additional info (there is one metod to add custom header, I forgot method
name)

I gave up long time ago to use this ..., so, if someone want to send spam
RFC is good start.
you may name that "comercial info" if you fell better ;) but this is still
spam :(

look for smtp envelope and have clear differnce betwen from, sender,
reply-to, ...


-----Original Message-----

From: "Ben Gallienne" <ben@webpoint0.com>

To: <spf-discuss@v2.listbox.com>

Date: Wed, 13 May 2009 13:30:23 +0100

Subject: RE: Re[8]: [spf-discuss] Trying to understand the best
recommendation for my client, help appreciated.




Alan,



I did send you a mail yesterday containing the links to the documentation

that I have. Maybe you didn't get it so it's copied below for reference.



Mail read:

"

Hi Alan,



Thanks for coming back to me again. I've done some searching around again

this morning and have been unable to find the relevant property that allows

me to set the envelope sender when generating an email using the cdo.message

in vbscript. I've been trying to find the answer in the msdn library

documentation for it so by all means if you're prepared to have a look then

it would be much appreciated. A URL to start with would be

http://msdn.microsoft.com/en-us/library/ms526311
[http://msdn.microsoft.com/en-us/library/ms526311](EXCHG.10).aspx , but
there

is lots of documentation there. The closest thing I have found to the answer

is on this page,

http://msdn.microsoft.com/en-us/library/ms526283
[http://msdn.microsoft.com/en-us/library/ms526283](EXCHG.10).aspx but it
seems

to suggest the field is read-only and I can't seem to find anything about

how it might get set programatically.



Thanks again for your help,



Ben

"



As it stands Sandy has kindly provided me with a suggested resolution to the

issue that I'm going to be testing out over the next couple of days with the

client, so I'm happy for this thread to now be closed, and thank you all of

you for your assistance, it's much appreciated.



Thanks,



Ben





-----Original Message-----

From: alan [mailto:spfdiscuss@alandoherty.net]

Sent: 13 May 2009 12:11

To: spf-discuss@v2.listbox.com

Subject: Re[8]: [spf-discuss] Trying to understand the best recommendation

for my client, help appreciated.



At 03:14 13/05/2009 Wednesday, Sanford Whiteman wrote:

>> Let's call a halt to measuring who's knowledge of what is bigger and

>> focus on answering the original question.

>

>Good idea. I am answering it off-list.



my view sod it! if help not wanted from those with expertise let them go and

f*ck up however they want



as to the libraries and OS/programming details



no, familiarity is unimportant to anyone but the programmer



a good programming team {i have been involved in many} has a protocol expert

assist to ensure protocol/BCP adherence

I just needed the api details /manual {but as i say if their to lazy to post

the uri, why should we bother}

to see if it can do the job and if it can advise on all the points where

they may /not adhere if not explicitly specifying values



in your case the datapoints without seeing the manual are



if you had bothered i could have told you where they are specified



IP{s} ensuring its has FcRDNS, ensuring FcRDNS has SPF-deny and csv-deny so

trojans and malware can't degrade the reputation of the mailer

helo/ehlo ensuring it adheres to RFC , has SPF, has CSV, points at all IP(s)

above, and in BCP is not==FcRDNS but is on same domain

mail from: <envelope sender> ensuring adheres to RFC ,it has SPF for IP(s)

above}, has MX's, is read/handled correctly



and in the mail

date: ensuring adheres to RFC

message-id: ensuring adheres to RFC

from: ensuring adheres to RFC , has sender-id, passes dkim/domainkeys if

domain has these, has MX's, is read/handled correctly

{and if issues with sender-id, dkim/domainkeys ensure sender: or other

workarounds are employed}



and any other as required by content being sent and origin {ie if web mail a

received: header showing protocol as http and originating ip and via for any

proxies}







-------------------------------------------

Sender Policy Framework: http://www.openspf.org [http://www.openspf.org/]

Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
[https://www.listbox.com/member/archive/735/=now]

RSS Feed: https://www.listbox.com/member/archive/rss/735/
[https://www.listbox.com/member/archive/rss/735/]

Powered by Listbox: http://www.listbox.com [http://www.listbox.com/]







-------------------------------------------

Sender Policy Framework: http://www.openspf.org [http://www.openspf.org/]

Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
[https://www.listbox.com/member/archive/735/=now]

RSS Feed: https://www.listbox.com/member/archive/rss/735/
[https://www.listbox.com/member/archive/rss/735/]

Powered by Listbox: http://www.listbox.com [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

At 19:44 13/05/2009 Wednesday, Sanford Whiteman wrote:
>> I'm out and won't be replying to this trolls followups
>
>Interesting redefinition of the term "troll"

entirely the definition someone continually being insulting to raise a reaction from newsgroup members is the origin of the term

>from someone striving so
>hard to try to get a paid consulting gig through this mailing list.

offering my services was no more than an aside

>This isn't a marketplace, kid. If you don't know how to help someone
>with the problem that is actually at hand, drop out.

i completely answered his original post
indicating that no headers are checked by spf
and advising him that it is only the HELO identity and the envelope from that are checked


>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!!}

>Then you gave a completely wrong answer about CDOSYS,

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

{i'm not claiming it is the only or best method just the first seen via a cursory glance a documentation}
and i quote directly from the page {and include the directions to same as it cannot be linked to directly
http://msdn.microsoft.com/en-us/library/ms527274(EXCHG.10).aspx

MSDNMSDN Home >MSDN Library>MSDN Learn>MSDN Downloads>MSDN Support>MSDN Community >MSDN Library >Win32 and COM Development >Messaging and Collaboration >CDO for Windows 2000 >Reference >Interfaces >IConfiguration Interface

Exchange Server 2003
IConfiguration Interface


Topic Last Modified: 2004-06-08 IConfiguration Interface

The IConfiguration interface defines properties and methods that you can use to access configuration information for Microsoft Collaboration Data Objects (CDO) objects. IID CD000022-8B95-11D1-82DB-00C04FB1625D
Extends IDispatch Member Summary

Properties Name Type Description

Fields

(Read-only)
ADODB.Fields

Fields* The Fields collection for the object.


Methods Name Description

Load Loads the specified configuration.

GetInterface
Reserved for future use. Remarks

You can access configuration settings on implementing objects by using the IConfiguration interface. The Fields property references an ADO Fields collection, and each Field object in the collection contains a name/value pair that defines part of a particular configuration. Consult the appropriate fields section of the reference for a list of valid fields to use. Most field names associated with configuration settings reside in the http://schemas.microsoft.com/cdo/configuration/ namespace.
Example

The following example demonstrates use of the IConfiguration interface on a CDO Configuration object. When sending messages from a machine that does not have a Simple Mail Transport Protocol (SMTP) service installed, you must send the message using an SMTP service on the network. A Configuration object is created, populated with configuration information, and then associated with a Message object using the IMessage.Configuration property. The SMTP server name, port, user display name, e-mail address, and credentials are all set as a part of the configuration. The table below lists the values used. Note that a field's fully qualified name must be used for reference. For configuration fields, all field names are prefixed with the http://schemas.microsoft.com/cdo/configuration/ namespace; for example, the fully qualified name for the smtpserver field is http://schemas.microsoft.com/cdo/configuration/smtpserver. To save space, the fields in the table below are listed without the
names
pace prefix.

Namespace: http://schemas.microsoft.com/cdo/configuration/ Field Value

smtpserver
mail.example.com

smtpserverport
67

smtpaccountname
My Name

sendemailaddress
"MySelf" <example@example.com>

smtpauthenticate
cdoBasic (1)

sendusername
domain\username

sendpassword
password

Smtpusessl
True (VARIANT_TRUE)

Sendusing
cdoSendUsingPort (2)


Once the Configuration object has been populated with relevant configuration information and associated with the Message object, the message is sent. In the following example, the CdoConfiguration module constants are used to identify the desired field. These constants are simply the full names of the fields in the namespace. For example, the CdoConfiguration constant cdoSMTPServer is equal to the string “http://schemas.microsoft.com/cdo/configuration/smtpserver.”



> after lying about having familiarity with Exchange.

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.

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

>Was it that you had too much familiarity to give the right answer? Then
>you gave another completely wrong answer after doing more "research"
>in Microsoft's documentation. I guess you're just too deep inside at
>this point.

i have only given one answer 1
anything else i have made is a quote from their documentation

>Perish the thought that you might actually have tried the technology
>first before answering with any degree of authority.

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

> Hmm, but then you would have actually spent uncompensated time helping someone out.

I did with my original response and others on this list will know i have not just given uncompensated advice but hand held many through complete re-design and writing of SPF records just because i wholeheartedly support the promotion and use of the standard

{anything that makes it easier for my and my customers mail servers to distinguish legitimate from illegitimate mail is compensation enough}

>Worse, you might have accidentally achieved some expertise in a Windows technology.

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

> 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

>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


>--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