12 May 2009 09:42
RE: Trying to understand the best recommendation for my client, help appreciated.
Ben Gallienne <ben <at> webpoint0.com>
2009-05-12 07:42:34 GMT
2009-05-12 07:42:34 GMT
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.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.com' > on behalf of 'someone <at> 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