Re: Milter Behavior

[Juri Haberland]

On 14.03.21 20:14, Juri Haberland wrote:
> On 14.03.21 12:00, Bastian Blank wrote:
>> On Sun, Mar 14, 2021 at 11:51:05AM +0100, Juri Haberland wrote:
>>> You should get this information from the AR-header. It should look like
>>> this:
>>> Authentication-Results: mx.example.org; dmarc=pass (p=quarantine
>>> dis=none) header.from=example.com;
>>> See the "p=quarantine dis=none" in the AR-header.
>> 
>> No.  You see "dmarc=pass".  The "p=quarantine" only tells you what the
>> DMARC policy wants to be done if the check fails, not if the check
>> failed.
> 
> Hmm, might be that I patched my OpenDMARC to a degree, where this behaviour
> was changed. I see something like that:
> 
> dmarc=fail (p=quarantine dis=none)
> 
> I'll look into this and issue pull-requests to the OpenDMARC team, if this
> is only in my branch.

Ah, I justed groked, that my example was wrong. It should have read:
Authentication-Results: mx.example.org; dmarc=fail (p=quarantine dis=none)
header.from=example.com

Cheers,
  Juri

Re: Milter Behavior

[Juri Haberland]

On 14.03.21 12:00, Bastian Blank wrote:
> On Sun, Mar 14, 2021 at 11:51:05AM +0100, Juri Haberland wrote:
>> You should get this information from the AR-header. It should look like
>> this:
>> Authentication-Results: mx.example.org; dmarc=pass (p=quarantine
>> dis=none) header.from=example.com;
>> See the "p=quarantine dis=none" in the AR-header.
> 
> No.  You see "dmarc=pass".  The "p=quarantine" only tells you what the
> DMARC policy wants to be done if the check fails, not if the check
> failed.

Hmm, might be that I patched my OpenDMARC to a degree, where this behaviour
was changed. I see something like that:

dmarc=fail (p=quarantine dis=none)

I'll look into this and issue pull-requests to the OpenDMARC team, if this
is only in my branch.

Cheers,
  Juri

Re: Milter Behavior

[Bastian Blank]

On Sun, Mar 14, 2021 at 11:51:05AM +0100, Juri Haberland wrote:
> You should get this information from the AR-header. It should look like
> this:
> Authentication-Results: mx.example.org; dmarc=pass (p=quarantine
> dis=none) header.from=example.com;
> See the "p=quarantine dis=none" in the AR-header.

No.  You see "dmarc=pass".  The "p=quarantine" only tells you what the
DMARC policy wants to be done if the check fails, not if the check
failed.

Bastian

-- 
We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!

Re: Milter Behavior

[Juri Haberland]

On 11/03/2021 10:22, Nick Tait wrote:
> On 11/03/21 11:37 am, Dan Mahoney wrote:
>> This fix has been merged to the opendmarc “Develop” branch as of a few 
>> minutes ago and will likely be in a 1.4.1 that comes out in the next few 
>> weeks, and will default to *not* quaranting the mail.  The option will be 
>> called HoldQuarantinedMessages (boolean option, default false).
> 
> Dan, I really appreciate you developing this feature, and look forward 
> to it making its way through to the Ubuntu repo in due course. Can I 
> please just ask what the behaviour will be when 
> HoldQuarantinedMessages=false? E.g. Will OpenDMARC add a new header to 
> signify this, or will it be reflected in the Authentication-Results 
> header? (FWIW Probably the latter would satisfy my requirements.)

You should get this information from the AR-header. It should look like
this:
Authentication-Results: mx.example.org; dmarc=pass (p=quarantine
dis=none) header.from=example.com;

See the "p=quarantine dis=none" in the AR-header.


  Juri

Re: Milter Behavior

[Dan Mahoney]

> On Mar 11, 2021, at 11:09 PM, Dominic Raferd  wrote:
> 
> On 12/03/2021 02:35, Dan Mahoney wrote:
>> 
>>> On Mar 11, 2021, at 1:00 AM, Dominic Raferd >> > wrote:
>>> 
>>> This works for me:
>>> 
>>> # grep ^RejectFailures /etc/opendmarc.conf # (note: false is the default 
>>> anyway)
>>> RejectFailures false
>> 
>> That’s orthogonal.
>> 
>> RejectFailures only affects domains tagged p=reject.  The feature I’m 
>> working with only affects p=quarantine.
> So you might think, but actually RejectFailures does affect domains tagged 
> p=quarantine: setting it to false (or, presumably, not setting it at all) 
> prevents the 'hold' action being reported back to the MTA (opendmarc v1.3.2).

I apologize.  So it does (opendmarc.c around line 3476).  Setting 
rejectfailures to “false” (the default) basically shuts off the milter’s 
ability to do anything but tag.

It might better be called “ActOnFailures”, because without it, reject doesn’t 
reject and quarantine doesn’t quarantine.

Perhaps the way I described *should* be the way it works.  Both behaviors 
should be individually tune-able.

(I will note that this is only marginally related to postfix — but a dialog is 
going and hopefully people searching for issues like “hey, why is my hold queue 
filling up) will find this here.  To everyone else, I apologize for the noise.

Stay safe out there,

-Dan

Re: Milter Behavior

[Dominic Raferd]

On 12/03/2021 02:35, Dan Mahoney wrote:


On Mar 11, 2021, at 1:00 AM, Dominic Raferd > wrote:


This works for me:

# grep ^RejectFailures /etc/opendmarc.conf # (note: false is the 
default anyway)

RejectFailures false


That’s orthogonal.

RejectFailures only affects domains tagged p=reject.  The feature I’m 
working with only affects p=quarantine.
So you might think, but actually RejectFailures does affect domains 
tagged p=quarantine: setting it to false (or, presumably, not setting it 
at all) prevents the 'hold' action being reported back to the MTA 
(opendmarc v1.3.2).

Re: Milter Behavior

[Dan Mahoney]

> On Mar 11, 2021, at 1:00 AM, Dominic Raferd  wrote:
> 
> On 10/03/2021 19:00, Dan Mahoney (Gushi) wrote:
>> All,
>> 
>> I'm working with the OpenDMARC folks on doing bug triage, and someone has 
>> requested that if a domain's policy says p=quarantine, that it should be 
>> "accepted" by postfix, and left for something like SpamAssassin to deal 
>> with.  (I don't see any specific handling in spamassassin that treats 
>> quaratine differently, but that's beside the point).
>> 
>> Per for RFCs, "quarantine" really means "queue for mail admins to deal with 
>> manually".  This is an old concept, going back in sendmail at least a 
>> decade, but it's been rarely used to this point.  Opendmarc makes this 
>> relatively common, and will catch mail admins by surprise.
>> 
>> So my question is (I've been reading the postfix milter docs for a half 
>> hour), is there any way to say (either globally or per-milter), "if the 
>> milter says hold, just deliver as normal?"
>> 
>> This is a thing that can be fixed in the milter, or fixed in postfix, but in 
>> an ideal world, both would exist.
>> 
>> (I mean, short of an every-minute cron job that just moves the things to the 
>> deliver queue).
>> 
>> -Dan
> 
> This works for me:
> 
> # grep ^RejectFailures /etc/opendmarc.conf # (note: false is the default 
> anyway)
> RejectFailures false

That’s orthogonal.

RejectFailures only affects domains tagged p=reject.  The feature I’m working 
with only affects p=quarantine.

-Dan

> 
> # postconf -n milter_header_checks
> milter_header_checks = pcre:/etc/postfix/milter_header_checks.pcre
> 
> # cat /etc/postfix/milter_header_checks.pcre
> # opendmarc is set not to reject failed emails, nor to instruct they
> #   be held (RejectFailures false) - but it will still add a header
> #   showing dmarc=fail: so here we can redirect them to a local
> #   mailbox (because they sometimes prove to be genuine
> #   i.e. from sender with misconfigured email server(s))
> /^Authentication-Results: my_authserv_id.*dmarc=fail \(p=(reject|quarantine)/ 
> REDIRECT dmarcfail@localhost

Re: Milter Behavior

[Dan Mahoney]

> On Mar 11, 2021, at 1:22 AM, Nick Tait  wrote:
> 
> On 11/03/21 11:37 am, Dan Mahoney wrote:
>> This fix has been merged to the opendmarc “Develop” branch as of a few 
>> minutes ago and will likely be in a 1.4.1 that comes out in the next few 
>> weeks, and will default to *not* quaranting the mail.  The option will be 
>> called HoldQuarantinedMessages (boolean option, default false).
> 
> Dan, I really appreciate you developing this feature, and look forward to it 
> making its way through to the Ubuntu repo in due course. Can I please just 
> ask what the behaviour will be when HoldQuarantinedMessages=false? E.g. Will 
> OpenDMARC add a new header to signify this, or will it be reflected in the 
> Authentication-Results header? (FWIW Probably the latter would satisfy my 
> requirements.)

I’m just the patch wrangler and doing some QA and cheerleading for the project.

Messages with HoldQuarantinedMessages will be allowed through with an 
Authentication-Results header, and will be processed just as if the 
sending-domain had specified p=none.

-Dan

Re: Milter Behavior

[Nick Tait]

On 11/03/21 11:37 am, Dan Mahoney wrote:

This fix has been merged to the opendmarc “Develop” branch as of a few minutes 
ago and will likely be in a 1.4.1 that comes out in the next few weeks, and 
will default to *not* quaranting the mail.  The option will be called 
HoldQuarantinedMessages (boolean option, default false).


Dan, I really appreciate you developing this feature, and look forward 
to it making its way through to the Ubuntu repo in due course. Can I 
please just ask what the behaviour will be when 
HoldQuarantinedMessages=false? E.g. Will OpenDMARC add a new header to 
signify this, or will it be reflected in the Authentication-Results 
header? (FWIW Probably the latter would satisfy my requirements.)


Thanks,

Nick.

Re: Milter Behavior

[Dominic Raferd]

On 10/03/2021 19:00, Dan Mahoney (Gushi) wrote:

All,

I'm working with the OpenDMARC folks on doing bug triage, and someone 
has requested that if a domain's policy says p=quarantine, that it 
should be "accepted" by postfix, and left for something like 
SpamAssassin to deal with.  (I don't see any specific handling in 
spamassassin that treats quaratine differently, but that's beside the 
point).


Per for RFCs, "quarantine" really means "queue for mail admins to deal 
with manually".  This is an old concept, going back in sendmail at 
least a decade, but it's been rarely used to this point.  Opendmarc 
makes this relatively common, and will catch mail admins by surprise.


So my question is (I've been reading the postfix milter docs for a 
half hour), is there any way to say (either globally or per-milter), 
"if the milter says hold, just deliver as normal?"


This is a thing that can be fixed in the milter, or fixed in postfix, 
but in an ideal world, both would exist.


(I mean, short of an every-minute cron job that just moves the things 
to the deliver queue).


-Dan


This works for me:

# grep ^RejectFailures /etc/opendmarc.conf # (note: false is the default 
anyway)

RejectFailures false

# postconf -n milter_header_checks
milter_header_checks = pcre:/etc/postfix/milter_header_checks.pcre

# cat /etc/postfix/milter_header_checks.pcre
# opendmarc is set not to reject failed emails, nor to instruct they
#   be held (RejectFailures false) - but it will still add a header
#   showing dmarc=fail: so here we can redirect them to a local
#   mailbox (because they sometimes prove to be genuine
#   i.e. from sender with misconfigured email server(s))
/^Authentication-Results: my_authserv_id.*dmarc=fail 
\(p=(reject|quarantine)/ REDIRECT dmarcfail@localhost

Re: Milter Behavior

[Wietse Venema]

Dan Mahoney:
> > I would be gratefuil if you can get this addressed in the Milter.
> > 
> > Please keep us informed of what happens. If it really does not work
> > out then we can look into b) add a feature to Postfix stable releases.
> > But the bar is high for changes to stable releases.
> 
> This fix has been merged to the opendmarc ?Develop? branch as of
> a few minutes ago and will likely be in a 1.4.1 that comes out in
> the next few weeks, and will default to *not* quaranting the mail.
> The option will be called HoldQuarantinedMessages (boolean option,
> default false).
> 
> Thanks to anyone who responded with further info.

Thank you for updating the Milter!

Wietse

Re: Milter Behavior

[Dan Mahoney]

> On Mar 10, 2021, at 1:45 PM, Wietse Venema  wrote:
> 
> Dan Mahoney:
>> I?ve been on the project for a few days.  I?m feeling a lot of
>> vitriol here.  Please don?t shoot the messenger.
> 
> The natural response would be to push back - fix the milter (the
> root cause of the problem) instead of the code that talks to it.
> 
 Either way, this is documentation that could go in both a postfix and 
 opendmarc doc.
>>> 
>>> What documentation? I will update Postfix documentation when there
>>> is a Postfix change, or when the documentation is inaccurate. It's
>>> not feasible to document issues with third-party milters.
>> 
>> "Note: some milters can cause mail to go to the Hold queue.  If
>> configuring a new milter please make sure this is your desired
>> behavior." was the entirety of what I was thinking.
> 
> Instead of documenting the current state, I think it is better to
> a) fix the milter, or if that does not work out, to b) add a
> workaround feature to Postfix code. My impression is that we are
> still in stage a).
> 
>>> If one Milter implementation unilaterally changes the meaning of
>>> 'quarantine' then I will be grateful if someone fixes that in the
>>> Milter so that it becomes consistent with the protocol spec.
>> 
>> I don't have the history there.  I'm detecting there is some, but
>> I just want to make better code.
> 
> I would be gratefuil if you can get this addressed in the Milter.
> 
> Please keep us informed of what happens. If it really does not work
> out then we can look into b) add a feature to Postfix stable releases.
> But the bar is high for changes to stable releases.

This fix has been merged to the opendmarc “Develop” branch as of a few minutes 
ago and will likely be in a 1.4.1 that comes out in the next few weeks, and 
will default to *not* quaranting the mail.  The option will be called 
HoldQuarantinedMessages (boolean option, default false).

Thanks to anyone who responded with further info.

Best,

-Dan

Re: Milter Behavior

[Wietse Venema]

Dan Mahoney:
> I?ve been on the project for a few days.  I?m feeling a lot of
> vitriol here.  Please don?t shoot the messenger.

The natural response would be to push back - fix the milter (the
root cause of the problem) instead of the code that talks to it.

> >> Either way, this is documentation that could go in both a postfix and 
> >> opendmarc doc.
> > 
> > What documentation? I will update Postfix documentation when there
> > is a Postfix change, or when the documentation is inaccurate. It's
> > not feasible to document issues with third-party milters.
> 
> "Note: some milters can cause mail to go to the Hold queue.  If
> configuring a new milter please make sure this is your desired
> behavior." was the entirety of what I was thinking.

Instead of documenting the current state, I think it is better to
a) fix the milter, or if that does not work out, to b) add a
workaround feature to Postfix code. My impression is that we are
still in stage a).

> > If one Milter implementation unilaterally changes the meaning of
> > 'quarantine' then I will be grateful if someone fixes that in the
> > Milter so that it becomes consistent with the protocol spec.
> 
> I don't have the history there.  I'm detecting there is some, but
> I just want to make better code.

I would be gratefuil if you can get this addressed in the Milter.

Please keep us informed of what happens. If it really does not work
out then we can look into b) add a feature to Postfix stable releases.
But the bar is high for changes to stable releases.

Wietse

Re: Milter Behavior

[Dan Mahoney]

> On Mar 10, 2021, at 12:36 PM, Wietse Venema  wrote:
> 
> Dan Mahoney (Gushi):
>>> Why not prepend a header (like Milters already do) and let Spamassassin
>>> etc. trigger on that label.
>> 
>> Let me try this a second time.
>> 
>> Fixing the milter to return success is the patch I'm currently working on 
>> for opendmarc. Telling me "why don't you fix your milter" is already 
>> underway.  My question was/is "does a knob to override this behavior in 
>> postfix exist?"
> 
> You replied affirmatively when I asked if you were asking for a
> Postfix change. What else can that mean than: it does not exist.

Respectfully, no, I didn’t.  Please re-read.

You described what the behavior is, in a first message:

(Message-Id: <4dwhxt0qwyzj...@spike.porcupine.org>)

Then, in a few-minutes-later message, asked if I was asking for a change:

(Message-Id: <4dwhcc0vmgzj...@spike.porcupine.org>)

None of my messages replied to 4Dwhcc0VmgzJrNy.

I replied to that first message with a sentence that started with “Yes, and…” 
meaning “Okay, I have read the docs and understand that’s the current behavior" 
 I should have read from your reply the implication there that "the behavior is 
not configurable”.  None of my replies were to the second message, because I 
had already been answering the first.

In my email to claus, my question was “I’d like to know the full set of options 
available”.  Not “Plz change postfix for me"

I do say that in an ideal world that allowing the administrator more control is 
good, but I’m trying to update the README for a product (ours) which has 
already caused people surprise (before I got here)— I can’t fix the fact that 
it’s done that thusfar.

I can only document and push patches to make it more friendly in the future.  
Which I am definitely trying to do.  

I’ve been on the project for a few days.  I’m feeling a lot of vitriol here.  
Please don’t shoot the messenger.

>> Either way, this is documentation that could go in both a postfix and 
>> opendmarc doc.
> 
> What documentation? I will update Postfix documentation when there
> is a Postfix change, or when the documentation is inaccurate. It's
> not feasible to document issues with third-party milters.

"Note: some milters can cause mail to go to the Hold queue.  If configuring a 
new milter please make sure this is your desired behavior.” was the entirety of 
what I was thinking.

> If one Milter implementation unilaterally changes the meaning of
> 'quarantine' then I will be grateful if someone fixes that in the
> Milter so that it becomes consistent with the protocol spec.

I don’t have the history there.  I’m detecting there is some, but I just want 
to make better code.

Stay safe,

-Dan

Re: Milter Behavior

[Wietse Venema]

Dan Mahoney (Gushi):
> > Why not prepend a header (like Milters already do) and let Spamassassin
> > etc. trigger on that label.
> 
> Let me try this a second time.
> 
> Fixing the milter to return success is the patch I'm currently working on 
> for opendmarc. Telling me "why don't you fix your milter" is already 
> underway.  My question was/is "does a knob to override this behavior in 
> postfix exist?"

You replied affirmatively when I asked if you were asking for a
Postfix change. What else can that mean than: it does not exist.

> Either way, this is documentation that could go in both a postfix and 
> opendmarc doc.

What documentation? I will update Postfix documentation when there
is a Postfix change, or when the documentation is inaccurate. It's
not feasible to document issues with third-party milters.

If one Milter implementation unilaterally changes the meaning of
'quarantine' then I will be grateful if someone fixes that in the
Milter so that it becomes consistent with the protocol spec.

Wietse

Re: Milter Behavior

[Benny Pedersen]

On 2021-03-10 20:55, Dan Mahoney (Gushi) wrote:


The simple answer I still haven't gotten, but assume from your
response, is "no, that knob doesn't exist"*

Is that correct?


postfix can only disable milters pr client ips

see smtpd_milter_maps

i have not seen what to do to only one milter

but i dont use milters anymore with fuglu in prequeue scanning where i 
can reject if desired

Re: Milter Behavior

[Dan Mahoney (Gushi)]

On Wed, 10 Mar 2021, Wietse Venema wrote:


Dan Mahoney (Gushi):

Postifix has a concept of quarantine. It is called the HOLD queue.

As of 2006, when the Milter says QUARANTINE, then Postfix will
quarantine the message, i.e. place it in the HOLD queue, for admins
to deal with manually.


Yes, and I am asking if there is a postfix knob that says "I know what the
milter says, but I want something different, because postfix doesn't know
about what will handle that message downstream of postfix
(procmail/spamassassin/imapfilter/etc).

I mean, maybe such a knob should exist if it doesn't, but this is also to
improve OpenDMARC's docs so mail admins aren't suddenly surprised at this
new action that's been off their radar for years.


Someone decided to change the meaning of Milter protcol responses
that were defined 15+ years ago, with a huge installed  base of
code that faithfully implements those responses, and they forgot
to tell the people who implement the software that receives those
responses.

That would be an unilateral protocol change.

Why not prepend a header (like Milters already do) and let Spamassassin
etc. trigger on that label.


Let me try this a second time.

Fixing the milter to return success is the patch I'm currently working on 
for opendmarc. Telling me "why don't you fix your milter" is already 
underway.  My question was/is "does a knob to override this behavior in 
postfix exist?"


Either way, this is documentation that could go in both a postfix and 
opendmarc doc.


The simple answer I still haven't gotten, but assume from your response, 
is "no, that knob doesn't exist"*


Is that correct?

*[and possibly "and it's unlikely to ever" or "but it's worthwhile in a 
future release"]


-Dan

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Re: Milter Behavior

[Wietse Venema]

Dan Mahoney (Gushi):
> > Postifix has a concept of quarantine. It is called the HOLD queue.
> >
> > As of 2006, when the Milter says QUARANTINE, then Postfix will
> > quarantine the message, i.e. place it in the HOLD queue, for admins
> > to deal with manually.
> 
> Yes, and I am asking if there is a postfix knob that says "I know what the 
> milter says, but I want something different, because postfix doesn't know 
> about what will handle that message downstream of postfix 
> (procmail/spamassassin/imapfilter/etc).
> 
> I mean, maybe such a knob should exist if it doesn't, but this is also to 
> improve OpenDMARC's docs so mail admins aren't suddenly surprised at this 
> new action that's been off their radar for years.

Someone decided to change the meaning of Milter protcol responses
that were defined 15+ years ago, with a huge installed  base of
code that faithfully implements those responses, and they forgot
to tell the people who implement the software that receives those
responses.

That would be an unilateral protocol change.

Why not prepend a header (like Milters already do) and let Spamassassin
etc. trigger on that label.

Wietse

Re: Milter Behavior

[Dan Mahoney (Gushi)]

On Wed, 10 Mar 2021, Claus Assmann wrote:


On Wed, Mar 10, 2021, Dan Mahoney (Gushi) wrote:


Yes, and I am asking if there is a postfix knob that says "I know what the
milter says, but I want something different, because postfix doesn't know

...

Why don't you "fix" the milter instead?  Then it would work the way
you want it for every MTA which supports milters.


Hey Claus,

I fondly remember your name from the Sendmail days and reading your 
excellent docs about how to get SMTP auth and sasl working.  I was at a 
tiny dialup ISP back in the day.


I'm literally in the process of trying to fix the milter as well (I have a 
patch for opendmarc, I'm about to create a pull request for it -- in 
fact my initial email was "let me just check postfix docs to make sure").


But in the interest of documentation, I'd like to know the full set of 
options available.


-Dan


--

-Dan Mahoney, JS, JB & SL, May 10th, 1997, Approx 1AM

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Re: Milter Behavior

[Claus Assmann]

On Wed, Mar 10, 2021, Dan Mahoney (Gushi) wrote:

> Yes, and I am asking if there is a postfix knob that says "I know what the
> milter says, but I want something different, because postfix doesn't know
...

Why don't you "fix" the milter instead?  Then it would work the way
you want it for every MTA which supports milters.

Re: Milter Behavior

[Dan Mahoney (Gushi)]

On Wed, 10 Mar 2021, Wietse Venema wrote:


Dan Mahoney (Gushi):

All,

I'm working with the OpenDMARC folks on doing bug triage, and someone has
requested that if a domain's policy says p=quarantine, that it should be
"accepted" by postfix, and left for something like SpamAssassin to deal
with.  (I don't see any specific handling in spamassassin that treats
quaratine differently, but that's beside the point).

Per for RFCs, "quarantine" really means "queue for mail admins to deal
with manually".  This is an old concept, going back in sendmail at least a
decade, but it's been rarely used to this point.  Opendmarc makes this
relatively common, and will catch mail admins by surprise.

So my question is (I've been reading the postfix milter docs for a half
hour), is there any way to say (either globally or per-milter), "if the
milter says hold, just deliver as normal?"


Postifix has a concept of quarantine. It is called the HOLD queue.

As of 2006, when the Milter says QUARANTINE, then Postfix will
quarantine the message, i.e. place it in the HOLD queue, for admins
to deal with manually.


Yes, and I am asking if there is a postfix knob that says "I know what the 
milter says, but I want something different, because postfix doesn't know 
about what will handle that message downstream of postfix 
(procmail/spamassassin/imapfilter/etc).


I mean, maybe such a knob should exist if it doesn't, but this is also to 
improve OpenDMARC's docs so mail admins aren't suddenly surprised at this 
new action that's been off their radar for years.


Best,

-Dan

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---

Re: Milter Behavior

[Wietse Venema]

Wietse Venema:
> Dan Mahoney (Gushi):
> > All,
> > 
> > I'm working with the OpenDMARC folks on doing bug triage, and someone has 
> > requested that if a domain's policy says p=quarantine, that it should be 
> > "accepted" by postfix, and left for something like SpamAssassin to deal 
> > with.  (I don't see any specific handling in spamassassin that treats 
> > quaratine differently, but that's beside the point).
> > 
> > Per for RFCs, "quarantine" really means "queue for mail admins to deal 
> > with manually".  This is an old concept, going back in sendmail at least a 
> > decade, but it's been rarely used to this point.  Opendmarc makes this 
> > relatively common, and will catch mail admins by surprise.
> > 
> > So my question is (I've been reading the postfix milter docs for a half 
> > hour), is there any way to say (either globally or per-milter), "if the 
> > milter says hold, just deliver as normal?"
> 
> Postifix has a concept of quarantine. It is called the HOLD queue.
> 
> As of 2006, when the Milter says QUARANTINE, then Postfix will
> quarantine the message, i.e. place it in the HOLD queue, for admins
> to deal with manually.

Are you asking for a Postfix change to IGNORE quarantine responses?

Wietse

Re: Milter Behavior

[Wietse Venema]

Dan Mahoney (Gushi):
> All,
> 
> I'm working with the OpenDMARC folks on doing bug triage, and someone has 
> requested that if a domain's policy says p=quarantine, that it should be 
> "accepted" by postfix, and left for something like SpamAssassin to deal 
> with.  (I don't see any specific handling in spamassassin that treats 
> quaratine differently, but that's beside the point).
> 
> Per for RFCs, "quarantine" really means "queue for mail admins to deal 
> with manually".  This is an old concept, going back in sendmail at least a 
> decade, but it's been rarely used to this point.  Opendmarc makes this 
> relatively common, and will catch mail admins by surprise.
> 
> So my question is (I've been reading the postfix milter docs for a half 
> hour), is there any way to say (either globally or per-milter), "if the 
> milter says hold, just deliver as normal?"

Postifix has a concept of quarantine. It is called the HOLD queue.

As of 2006, when the Milter says QUARANTINE, then Postfix will
quarantine the message, i.e. place it in the HOLD queue, for admins
to deal with manually.

Wietse

> This is a thing that can be fixed in the milter, or fixed in postfix, but 
> in an ideal world, both would exist.
> 
> (I mean, short of an every-minute cron job that just moves the things to 
> the deliver queue).
> 
> -Dan
> 
> -- 
> 
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> FB:  fb.com/DanielMahoneyIV
> LI:   linkedin.com/in/gushi
> Site:  http://www.gushi.org
> ---
> 
>