SPF Policy Daemon: Sender vs. Recipient Rejected?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

SPF Policy Daemon: Sender vs. Recipient Rejected?

Jim Seymour-2
Hi All,

I'm using the SPF policy daemon.  Works great (or appears to, anyway),
save one thing: The rejects claim "Recipient address rejected," when,
in reality, it's the sender's address that's being rejected.  This leads
to confusion.

Short of reworking my rules so I can place the SPF check under
smtpd_sender_restrictions (I have everything under recipient
restrictions), which I'm guessing would fix the problem, is there any
way to persuade SPF policy daemon rejects to say the right thing?

Thanks,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

Ralf Hildebrandt
* James Seymour <[hidden email]>:

> Hi All,
>
> I'm using the SPF policy daemon.  Works great (or appears to, anyway),
> save one thing: The rejects claim "Recipient address rejected," when,
> in reality, it's the sender's address that's being rejected.  This leads
> to confusion.
>
> Short of reworking my rules so I can place the SPF check under
> smtpd_sender_restrictions (I have everything under recipient
> restrictions), which I'm guessing would fix the problem, is there any
> way to persuade SPF policy daemon rejects to say the right thing?

Actually it's postfix reporting this, so your approach of putting it
into smtpd_sender_restrictions is looking better

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  CharitĂ© - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  [hidden email] | http://www.charite.de
           
Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

DTNX Postmaster
On May 8, 2012, at 14:34, Ralf Hildebrandt wrote:

> * James Seymour <[hidden email]>:
>> Hi All,
>>
>> I'm using the SPF policy daemon.  Works great (or appears to, anyway),
>> save one thing: The rejects claim "Recipient address rejected," when,
>> in reality, it's the sender's address that's being rejected.  This leads
>> to confusion.
>>
>> Short of reworking my rules so I can place the SPF check under
>> smtpd_sender_restrictions (I have everything under recipient
>> restrictions), which I'm guessing would fix the problem, is there any
>> way to persuade SPF policy daemon rejects to say the right thing?
>
> Actually it's postfix reporting this, so your approach of putting it
> into smtpd_sender_restrictions is looking better

Part of it is the default reply from Postfix, which depends on where
you put the restriction. The rest is the reply from your SPF policy
daemon, which Postfix appends to its default reply.

For example, this is from ours, from earlier today;

====
Transcript of session follows.

Out: 220 nenya.dtnx.net ESMTP
In:  EHLO relay3-d.mail.gandi.net
Out: 250-nenya.dtnx.net
Out: 250-PIPELINING
Out: 250-SIZE 31457280
Out: 250-ENHANCEDSTATUSCODES
Out: 250 8BITMIME
In:  MAIL FROM:<[hidden email]> SIZE=25982 BODY=7BIT
Out: 250 2.1.0 Ok
In:  RCPT TO:<[hidden email]>
Out: 550 5.7.1 <[hidden email]>: Recipient address
rejected: will not accept '[hidden email]' from
'217.70.183.195'; SPF fail - not authorized
In:  DATA
Out: 554 5.5.1 Error: no valid recipients
In:  RSET
Out: 250 2.0.0 Ok
In:  QUIT
Out: 221 2.0.0 Bye
====

The '550 ... rejected:' is Postfix, the rest is the reply Postfix got
from the SPF policy daemon. Customizing that reply may be another
option to clarify what is happening.

Cya,
Jona

Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

Benny Pedersen
Den 2012-05-08 15:43, Jona - DTNX Postmaster skrev:

> The '550 ... rejected:' is Postfix, the rest is the reply Postfix got
> from the SPF policy daemon. Customizing that reply may be another
> option to clarify what is happening.

reject_unlisted_recipient before greylist / spf test solves this

Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

Jim Seymour-2
On Wed, 09 May 2012 01:22:27 +0200
Benny Pedersen <[hidden email]> wrote:

> Den 2012-05-08 15:43, Jona - DTNX Postmaster skrev:
>
> > The '550 ... rejected:' is Postfix, the rest is the reply Postfix
> > got from the SPF policy daemon. Customizing that reply may be
> > another option to clarify what is happening.
>
> reject_unlisted_recipient before greylist / spf test solves this
>

Eh?  Explain, please?

Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

DTNX Postmaster
On May 10, 2012, at 14:40, James Seymour wrote:

> On Wed, 09 May 2012 01:22:27 +0200
> Benny Pedersen <[hidden email]> wrote:
>
>> Den 2012-05-08 15:43, Jona - DTNX Postmaster skrev:
>>
>>> The '550 ... rejected:' is Postfix, the rest is the reply Postfix
>>> got from the SPF policy daemon. Customizing that reply may be
>>> another option to clarify what is happening.
>>
>> reject_unlisted_recipient before greylist / spf test solves this
>>
>
> Eh?  Explain, please?

I think Benny assumed that the address in my example was the actual
address, instead of my 'xxx' obfuscated version of it. The real address
does exist, which means the above does not apply, AFAIK.

As for the question itself, we had a look at moving the SPF check into
the sender restrictions, but it makes things quite a bit more
complicated, and therefore harder to maintain, more prone to errors and
so on.

Also, since the SPF policy daemon does both HELO and sender checks, the
sender restrictions aren't really optimal either, so we're keeping
everything in the recipient restrictions.

People tend to be confused by SPF anyway. Most of our time with
complaints based on SPF rejections is spent explaining what it is, how
it is published by them (or their provider) and so on.

If they even read the error message to begin with, heh.

Cya,
Jona

Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

Benny Pedersen
In reply to this post by Jim Seymour-2
Den 2012-05-10 14:40, James Seymour skrev:

> Eh?  Explain, please?

check_policy_service must be after reject_unlisted_recipient

# example fault
check_policy_service inet:10.3.19.214:10031
reject_unlisted_recipient

if port 10031 is a greylist daemon it will greylist users that does not
exists

# example ok
reject_unlisted_recipient
check_policy_service inet:10.3.19.214:10031

that makes sure greylist is not called for unlisted users that will be
rejected as unknown users later

for spf the logs will be more clear aswell, i cant explain it more



Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

Benny Pedersen
In reply to this post by DTNX Postmaster
Den 2012-05-10 16:21, DTNX Postmaster skrev:

> If they even read the error message to begin with, heh.

do one need to know how to change a wheel on a wagon to drive it ? :=)



Reply | Threaded
Open this post in threaded view
|

Re: SPF Policy Daemon: Sender vs. Recipient Rejected?

Jim Seymour-2
In reply to this post by Benny Pedersen
On Thu, 10 May 2012 23:23:43 +0200
Benny Pedersen <[hidden email]> wrote:

> Den 2012-05-10 14:40, James Seymour skrev:
>
> > Eh?  Explain, please?
>
> check_policy_service must be after reject_unlisted_recipient
[snip]
>
> that makes sure greylist is not called for unlisted users that will
> be rejected as unknown users later
[snip]

That does not solve the problem at hand.  (Besides: One might argue
that generating a delay in a "user does not exist" response is a Good
Thing.  Slows the spammers down and really doesn't have all that much
effect on legitimate senders.)

And, with that, I guess we're done with this discussion.  Only solution
is to move the SPF check to sender restrictions, and I don't care to
engage in that complexity.

Thanks for the feedback, everybody.

Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.