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