Re: [Fwd: Re: No SPF_FAIL flag, why?]

[Matt <lm...@gmail.com>]

> That doesn't make sense. Maybe I am misunderstanding this. From openspf.org:
>
> What does SPF actually DO?
>
> Suppose a spammer forges a hotmail.com address and tries to spam you.
>
> They connect from somewhere other than Hotmail.
>
> When his message is sent, you see MAIL FROM: <fo...@hotmail.com>,
> but you don't have to take his word for it. You can ask Hotmail if the IP
> address comes from their network.

The MTA never really sees whats in the headers.  It only adds to the
headers.  When an SMTP connection first begins the connecting MTA says
helo this such-and-such@such-n-such-domain.com.  Thats what SPF looks
at.  The MTA then adds that as the return path to the headers.

>>Return-path: <pp...@pl4jg>

That return path looks flaky.  I would think spamassassin would have
some way of since its not a valid domain consider it suspect.  Not
sure though.

Matt

Re: [Fwd: Re: No SPF_FAIL flag, why?]

[Russell Jones <rj...@eggycrew.com>]

It is completely accurate and copied and pasted from the message file 
itself.

I am running Exim. What configuration should I be looking at on how to 
block messages with return paths like that?

Dave Funk wrote:
> On Wed, 27 Feb 2008, Matt wrote:
>
>> The MTA never really sees whats in the headers.  It only adds to the
>> headers.  When an SMTP connection first begins the connecting MTA says
>> helo this such-and-such@such-n-such-domain.com.  Thats what SPF looks
>> at.  The MTA then adds that as the return path to the headers.
>
> Actually there is a "HELO hostname.domain" field and then the
> "RECPT FROM: such-and-such@such-n-such-domain.com" field.
> Both can be tested with SPF but it is the second (AKA envelope-from)
> which results in the Return-path header
>
>>>> Return-path: <pp...@pl4jg>
>>
>> That return path looks flaky.  I would think spamassassin would have
>> some way of since its not a valid domain consider it suspect.  Not
>> sure though.
>
> If that accuratly represents the messages's envelope-from address
> then the OP has a problem at the MTA level. The MTA should do the most
> basic validation of the envelope-from (make sure that the domain name
> represents a valid domain via DNS).
> In that case the message should have been blocked at the MTA and never
> even made it to SA.
>

Re: [Fwd: Re: No SPF_FAIL flag, why?]

[Dave Funk <db...@engineering.uiowa.edu>]

On Wed, 27 Feb 2008, Matt wrote:

> The MTA never really sees whats in the headers.  It only adds to the
> headers.  When an SMTP connection first begins the connecting MTA says
> helo this such-and-such@such-n-such-domain.com.  Thats what SPF looks
> at.  The MTA then adds that as the return path to the headers.

Actually there is a "HELO hostname.domain" field and then the
"RECPT FROM: such-and-such@such-n-such-domain.com" field.
Both can be tested with SPF but it is the second (AKA envelope-from)
which results in the Return-path header

>>> Return-path: <pp...@pl4jg>
>
> That return path looks flaky.  I would think spamassassin would have
> some way of since its not a valid domain consider it suspect.  Not
> sure though.

If that accuratly represents the messages's envelope-from address
then the OP has a problem at the MTA level. The MTA should do the most
basic validation of the envelope-from (make sure that the domain name
represents a valid domain via DNS).
In that case the message should have been blocked at the MTA and never
even made it to SA.

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{