
spfdiscuss at alandoherty
May 12, 2009, 10:41 AM
Post #6 of 41
(3117 views)
Permalink
|
|
RE: Trying to understand the best recommendation for my client, help appreciated.
[In reply to]
|
|
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 [at] cypressintegrated] >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' >> on behalf of 'someone [at] clientscustomer'. > >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
|