We have published SRS records, and they are tested and working fine.
However, we have "send this article to a friend" functionality on our
website, which runs Win2k. We use the CDOSYS and .NET System object
models for sending emails from these web servers.
Currently, we set the "From:" property of the message as the third-party
person's name, and then added a "Sender:" header indicating it came from
our web servers. This gives us the nice, logical "From:
<webservers@bai.org> On Behalf Of Joe Schmoe" in most MUAs.
"
However, I believe just setting the "From" field in CDO or .NET sets
both the envelope *and* header "From:" to the third-party person. This
is not in line with SPF as far as I can tell, since we are periodically
sending messages from our MTA with non-bai.org envelope senders.
From what I've read on the SPF site, I think I should be setting the
envelope sender to "webservers@bai.org", setting the "From" header to
the third party, and adding our "sender: <webservers@bai.org>" header as
before. Is this correct? If so, does anybody know how to control the
envelope sender independently from the From header in CDO? Do I set the
message object's FROM property to our web server address, then add a
"From:" header? Is there site out there where I can send a message to
see what both the envelope and headers look like?
Or do I need to use SRS for this to properly relay bounces to the third
party? I think I'm supposed to, but I do not have any SRS implementation
installed on these Win2k MTAs. Would it be against RFCs to ignore the
bounces? I mean, the webservers@bai.org is a valid address, so the
outgoing message does have a valid return path. We don't really care if
the third party ever sees the bounces.
Thanks for any help... I'm disappointed I couldn't figure this out on my
own from the documentation on SPF and other sites, but the documentation
seems to be a bit scattered over several sites. Perhaps the draft RFC
might help me? Is it available yet online? Or does that not include this
sort of information?
Thanks again,
Ryan Malayter
Bank Administration Institute
Chicago, Illinois, USA
PGP Key: http://www.malayter.com/pgp-public.txt
=========================
All problems can be solved by diplomacy, but violence and treachery are
equally effective, and more fun.
-Anonymous
However, we have "send this article to a friend" functionality on our
website, which runs Win2k. We use the CDOSYS and .NET System object
models for sending emails from these web servers.
Currently, we set the "From:" property of the message as the third-party
person's name, and then added a "Sender:" header indicating it came from
our web servers. This gives us the nice, logical "From:
<webservers@bai.org> On Behalf Of Joe Schmoe" in most MUAs.
"
However, I believe just setting the "From" field in CDO or .NET sets
both the envelope *and* header "From:" to the third-party person. This
is not in line with SPF as far as I can tell, since we are periodically
sending messages from our MTA with non-bai.org envelope senders.
From what I've read on the SPF site, I think I should be setting the
envelope sender to "webservers@bai.org", setting the "From" header to
the third party, and adding our "sender: <webservers@bai.org>" header as
before. Is this correct? If so, does anybody know how to control the
envelope sender independently from the From header in CDO? Do I set the
message object's FROM property to our web server address, then add a
"From:" header? Is there site out there where I can send a message to
see what both the envelope and headers look like?
Or do I need to use SRS for this to properly relay bounces to the third
party? I think I'm supposed to, but I do not have any SRS implementation
installed on these Win2k MTAs. Would it be against RFCs to ignore the
bounces? I mean, the webservers@bai.org is a valid address, so the
outgoing message does have a valid return path. We don't really care if
the third party ever sees the bounces.
Thanks for any help... I'm disappointed I couldn't figure this out on my
own from the documentation on SPF and other sites, but the documentation
seems to be a bit scattered over several sites. Perhaps the draft RFC
might help me? Is it available yet online? Or does that not include this
sort of information?
Thanks again,
Ryan Malayter
Bank Administration Institute
Chicago, Illinois, USA
PGP Key: http://www.malayter.com/pgp-public.txt
=========================
All problems can be solved by diplomacy, but violence and treachery are
equally effective, and more fun.
-Anonymous