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(_at_)cypressintegrated(_dot_)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(_at_)client(_dot_)com'
on behalf of 'someone(_at_)clientscustomer(_dot_)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