oops
Sorry about that, accidentally hit control-enter! dang!
i did have a point.
anyhow, the php/bsd/apache thing looks like this
250-oo50 Hi server1.managean.com [69.20.9.90]
dispatching MAIL From:<nobody(_at_)server1(_dot_)managean(_dot_)com>
250 nobody(_at_)server1(_dot_)managean(_dot_)com, sender OK it is wery exciting.
dispatching RCPT To:<nananitty(_at_)emkdesign(_dot_)com>
250 nananitty(_at_)emkdesign(_dot_)com, recipient ok
dispatching DATA
354 go ahead
250 Queued!
dispatching QUIT
221 oo50 bye. Have a wonderfulo dayo.
it uses the machine process account for MAIL FROM while talking to the
SMTP server.
So, here is the thing. If the MS server used the account address in the
MAIL-FROM then I don't see why there would need to be any need to use
PRA to begin with.
with SPF checking EHLO and MAIL-FROM, it is looking at the right place
to do the check, IMHO.
I am trying to make some sense of PRA here.
Basically, their example problem involves a "from" address of the person
sending the form.
If we base the SPF check on the "From" address in the header, then it
would obviously fail because that domain wouldn't necessarily allow
email to come from that machine that sent the form.
So I suppose they are trying to put this header in there that says
"machine X sent this on behalf of blah(_at_)freakingexample(_dot_)com" - Does that
sound about right?
Going back to the way the MS server works, if it just did a MAIL FROM
based on the machine domain like the other example, there wouldn't need
to be an SPF check on the header at all, right?
It just sounds like their software operates in a way that won't work
with checks before DATA so it needs to check the header. ???
Waitman
Waitman C Gobble II wrote:
Seth Goodman wrote:
Many intelligent readers will cry "foul", this is not fair. It isn't,
but that is our system.
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
According to that page, If you want to check the SPF record in
incoming mail, you need to update to Sender ID compliant software to
check PRA of incoming mail.
I guess I don't understand something. Are we dropping the MAIL-TO and
EHLO and source IP check altogether and basing the checks on what's in
the DATA?
I have been trying to figure out what the difference really is,
reading the 'example problems' that PRA is supposed to address.
one is the 'contact form that is "from" the user's input address'
When I do such a thing on a bsd machine with sendmail using a php
script, I get this
On an MS server using ASP and CDO I get this:
250-oo50 Hi h-68-165-182-37.lsanca54.covad.net [68.165.182.37]
dispatching MAIL FROM:<web(_dot_)server(_at_)buenaparkchamber(_dot_)org>
250 web(_dot_)server(_at_)buenaparkchamber(_dot_)org, sender OK it is wery
exciting.
dispatching RCPT TO:<contact(_at_)buenaparkchamber(_dot_)org>
250 contact(_at_)buenaparkchamber(_dot_)org, recipient ok
dispatching DATA
354 go ahead
250 Queued!
dispatching QUIT
221 oo50 bye. Have a wonderfulo dayo.
From what I understand, the CDO thingy just drops a text email into
the outgoing queue for processing. So, it is using the FROM address of
the message to do MAIL FROM.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com