messages getting in the hold queue

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

messages getting in the hold queue

richard lucassen
Hello list,

I'm playing with a new setup and I'm mucking about with it quite a lot
of course, but sometimes I get messages sent to the hold queue and
I didn't postsuper them there. What could be the reason for this? The
doc http://www.postfix.org/QSHAPE_README.html#hold_queue does not
clarify this for me.

It just happened to the message of Ron Wheeler (X-Spam-Score: -2.299)
in the "Postfix 20 years ago" thread.

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

Wietse Venema
richard lucassen:

> Hello list,
>
> I'm playing with a new setup and I'm mucking about with it quite a lot
> of course, but sometimes I get messages sent to the hold queue and
> I didn't postsuper them there. What could be the reason for this? The
> doc http://www.postfix.org/QSHAPE_README.html#hold_queue does not
> clarify this for me.
>
> It just happened to the message of Ron Wheeler (X-Spam-Score: -2.299)
> in the "Postfix 20 years ago" thread.

Try this:
$ grep hold /the/maillog/file

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

richard lucassen
On Sun, 12 Feb 2017 15:43:09 -0500 (EST)
[hidden email] (Wietse Venema) wrote:

> > I'm playing with a new setup and I'm mucking about with it quite a
> > lot of course, but sometimes I get messages sent to the hold queue
> > and I didn't postsuper them there. What could be the reason for
> > this? The doc http://www.postfix.org/QSHAPE_README.html#hold_queue
> > does not clarify this for me.
> >
> > It just happened to the message of Ron Wheeler (X-Spam-Score:
> > -2.299) in the "Postfix 20 years ago" thread.
>
> Try this:
> $ grep hold /the/maillog/file

mail.info: Feb 12 19:38:46 postfix/cleanup[6963]: 239803F990:
milter-hold: END-OF-MESSAGE from english-breakfast.cloud9.net
[168.100.1.7]: milter triggers HOLD action;
from=<[hidden email]> to=<[hidden email]>
proto=ESMTP helo=<english-breakfast.cloud9.net>

mail.info: Feb 12 21:10:58 postfix/postsuper[9039]: 239803F990:
released from hold
mail.info: Feb 12 21:10:58 postfix/postsuper[9039]: Released from hold:
1 message

Hmm, must be the SPF milter I fear. Apparently I'm not the only one.
Don't know if it has been resolved. For the moment I'll let cron check
for files in /var/spool/postfix/hold/

Thnx!

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

richard lucassen
On Sun, 12 Feb 2017 22:01:05 +0100
richard lucassen <[hidden email]> wrote:

It must be OpenDMARC:

host -t txt artifact-software.com
"v=spf1 mx -all"

host -t txt _dmarc.artifact-software.com
"v=DMARC1; pct=100; p=quarantine; adkim=r; aspf=r"

And as this mail is sent by cloud9, opendmarc does what it is supposed
to do.

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

Benny Pedersen-2
In reply to this post by richard lucassen
sid-milter?

dont use it, its still checking sender-id

that is not spf
Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

Viktor Dukhovni
In reply to this post by richard lucassen
On Sun, Feb 12, 2017 at 10:10:05PM +0100, richard lucassen wrote:

> host -t txt _dmarc.artifact-software.com
> "v=DMARC1; pct=100; p=quarantine; adkim=r; aspf=r"
>
> And as this mail is sent by cloud9, opendmarc does what it is supposed
> to do.

Say no to DMARC.  Don't make the mistake of outsourcing your inbound
email policy to random strangers who either don't understand all
the ways in which DMARC is flawed, or don't care about collateral
damage.

There are good reasons why RFC7489 is an "informational" rather
than a "standards track" RFC.  While DMARC may reduce Yahoo's abuse
desk costs, we don't have to play along.  Though DMARC may reject
some forged Yahoo email, there's still plenty of 419 email from
the real Yahoo.

DO NOT publish DMARC policy.  DO NOT check DMARC policy, except
perhaps as a small bump in a composite spam score.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

Josh Good
On 2017 Feb 12, 21:26, Viktor Dukhovni wrote:

> DO NOT publish DMARC policy.  DO NOT check DMARC policy, except
> perhaps as a small bump in a composite spam score.

The "DO NOT publish DMARC policy" is a bit extreme, IMHO.

I find it useful, and without any bad consequences, to publish a DMARC
policy of "p=none", and then collect the DMARC reports other mail operator
send to me, so that I know how much my domains are being spoofed, and
from what network addresses/blocks. That is valuable insight.

Even if we were to condemn DMARC, its reporting capabilities are worthy
by themselves.

Regards,

--
Josh Good

Reply | Threaded
Open this post in threaded view
|

Re: messages getting in the hold queue

richard lucassen
In reply to this post by Viktor Dukhovni
On Sun, 12 Feb 2017 21:26:55 +0000
Viktor Dukhovni <[hidden email]> wrote:

> > host -t txt _dmarc.artifact-software.com
> > "v=DMARC1; pct=100; p=quarantine; adkim=r; aspf=r"
> >
> > And as this mail is sent by cloud9, opendmarc does what it is
> > supposed to do.
>
> Say no to DMARC.  Don't make the mistake of outsourcing your inbound
> email policy to random strangers who either don't understand all
> the ways in which DMARC is flawed, or don't care about collateral
> damage.

Ok, but it is the inbound email policy of only /their/ domain. Like SPF,
it's the responsability of the owner of the domain, not the
responsability of the receiver. If someone fscks up the settings of
his/her domain, it's not my responsibility. If someone doesn't publish
glue records in DNS or uses a DNS servers that give different responses,
it's not my problem.

> There are good reasons why RFC7489 is an "informational" rather
> than a "standards track" RFC.

Well Viktor, I'm eager to know these reasons :) For the moment I do not
see any harm in applying DMARC, but I'd like to hear your objections.

> While DMARC may reduce Yahoo's abuse
> desk costs, we don't have to play along.  Though DMARC may reject
> some forged Yahoo email, there's still plenty of 419 email from
> the real Yahoo.

DMARC is *not* the ultimate solution to spam. Spammers know how it works
and they will do their utmost to bypass filtering when they deliver
their bullshit. I just don't want other people to misuse the domains I
own.

> DO NOT publish DMARC policy.

That's the choice of the owner of the domain. And his/her
responsability.

> DO NOT check DMARC policy, except
> perhaps as a small bump in a composite spam score.

That's the choice of the receiver. And his/her resposabilty.

If I ask you to reject mail from my domain dos.nl which is not
signed and coming from an ip that is not in my -all SPF record, who am
I to tell you not to accept the mail anyway? If you want it, go ahead,
you're welcome! :)

R.

--
richard lucassen
http://contact.xaq.nl/