Re: Fwd: Re: Maybe simple question

--marrandy <marrandy(_at_)chaossolutions(_dot_)org> wrote:

> spf is checking the :-
> MAIL FROM:<owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
> by stripping the left parts away leaving  listbox.com, looking it up in
> DNS  (with the rule you are using, a, mx, ptr or whatever, and comparing
> it  against the IP 207.8.214.5

A good explanation of the SMTP transaction.

A minor correction, in this example we would check SPF records for 
"v2.listbox.com" first.  The answer is "v=spf1 redirect=listbox.com". 
Normally if there is no redirect you would not walk up the chain, I don't 
think.

In my experience, the Envelope address (meaning what the MTA said in the 
MAIL FROM: part of the transaction) is usually recorded as "Return-Path"... 
I believe that is why Return-Path is shown at the TOP of the headers; it is 
added last, by the last MTA to receive it, based on what the other MTA told 
it.  Return-Path may or may not appear in your mail program, but if it does 
that is a good indication that it was in the transaction outside of the 
DATA.  The DATA includes all the headers and all the body, but the MAIL 
FROM command is seen by the server before receiving any headers.
*Often* the "Sender:" header is the same as the Mail From 
command/transaction and return-path, but sometimes "Sender:" is not shown 
at all.  There is NO rule that says the From: address in the header has to 
match the Mail From command, and in the case of mailing lists it definitely 
won't, since you want bounces to go back to the list server, and not each 
sender, which might be different from where replies might go.

To emphasize what Martin and others have said... It is pretty common to 
have 4 servers handling your mail.  If the sender sends it to an 
intermediate server that is not really the "outgoing" server, that's 2 on 
the sender side.  If the To: address domain has an "edge" server and a 
"user mailbox" server, then that's 2 on the receiver side.
BUT, and this is the important point, the path is NOT random.  You either 
work for the sender or you work for the receiver.  If it is being relayed 
by a third party, that's a sure sign that something is fishy, and the 
server allowing third-party relay is likely to get blacklisted soon.  For 
legitimate email, it goes from the sender's servers to the receivers 
servers (such as from smtp03.mrf.mail.rcn.net to apex.listbox.com) and NOT 
"randomly" by way of AOL, MSN, the government or anyone else.
So THIS point in the transaction is where you want to catch it, when the 
agent of the sender is contacting the agent of the receiver.   Ideally with 
SPF you should be able to accept or shut down the connection based only on 
the envelope address and DNS - similar to how Sendmail and other mailers do 
basic checks like "Hey youkickedmydog.net doesn't even resolve properly so 
I'm not going to accept mail From it if I clearly can't reply TO it."  SPF 
just takes that type of check to the next level.  Either the sending server 
is authorized to send on behalf of that domain, according to that domain's 
DNS, or it isn't.  The check can be done without even receiving any headers 
or body of the message.
If it is forwarded by a listserver, that adds more Received: lines, but the 
envelope address has changed, some mail servers record this as "Received by 
X from Y FOR <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>"  Then it becomes "mail from 
v2.listbox.com" and not "mail from nekodojo.org".

It is also possible to apply SPF logic after the fact, looking at the 
Received: headers, but you would have to REALLY trust your receiving server 
to log everything correctly (IP address of the previous mailer, return-path 
or other representation of the envelope address, etc).  Spamassassin is an 
example of where you might do this, but it's not as good as checking during 
the transaction, on the edge of your network.  If you process after the 
fact you have already paid the cost of receiving the data and storing it 
somewhere.

I am not sure if this info is being helpful to Edward's original concern. 
It is not really clear to me if Edward is misunderstanding how SMTP works, 
or what SPF is supposed to do, or if he is not explaining his 
problem/concern well enough for me to understand.  So, I will wrap it up 
here for now.  Hopefully the above info helps, but if not, please continue 
to rephrase and clarify the question and myself and others will answer 
patiently.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.3.txt
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡