“Does this mean that a condition in smtpd_helo_restrcitiosn which
triggers a "REJECT" will, upon entering RCPTO TO mode, result in the
rejection with nothing else evaluated?”
Yes but it doesn’t matter in which of the 5 lists it is encountered.
Once REJECT is encountered, all evaluation ends…
On 2021-03-10 15:08, Noel Jones wrote:
> This is incorrect. With the default smtpd_delay_reject=yes, all
> evaluations are performed after the client sends RCPT TO.
Thanks for clarification. Reading the docs of delay_reject brings up
another question:
"Wait until the RCPT TO command before
Antonio Leding:
> >>> START Recipient address RESTRICTIONS <<<
>
> Lots of log messages related to SMTPD_RECIPIENT_RESTRICTIONS evaluation
>
> >>> END Recipient address RESTRICTIONS <<<
> >>> START Recipient address RESTRICTIONS <<<
>
> Lots of log messages related to
On Wed, 10 Mar 2021 21:55:43 +0100, Christian Göttsche
wrote:
> Am Mi., 10. März 2021 um 21:44 Uhr schrieb Wietse Venema
> :
> >
> > Christian G?ttsche:
> > > -g -O2 -I. -I../../include -DLINUX4 -c xsasl_cyrus_server.c
> > > xsasl_cyrus_server.c:185:26: warning: initialization of ?int
> > >
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.
>
>
Hello all - couple of questions…
Q1: Recipient & relay restriction evaluation order
Regarding the evaluation order of the SMTPD_RECIPIENT & SMTPD_RELAY
restriction lists, there have been a few message threads that discuss
the disparity between the Postfix documentation and the actual
> 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
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
> 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
Am Mi., 10. März 2021 um 21:44 Uhr schrieb Wietse Venema :
>
> Christian G?ttsche:
> > -g -O2 -I. -I../../include -DLINUX4 -c xsasl_cyrus_server.c
> > xsasl_cyrus_server.c:185:26: warning: initialization of ?int
> > (*)(void)? from incompatible pointer type ?int (*)(void *, char **)?
> >
Christian G?ttsche:
> -g -O2 -I. -I../../include -DLINUX4 -c xsasl_cyrus_server.c
> xsasl_cyrus_server.c:185:26: warning: initialization of ?int
> (*)(void)? from incompatible pointer type ?int (*)(void *, char **)?
> [-Wincompatible-pointer-types]
> 185 | {SASL_CB_GETCONFPATH,_getconfpath,
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
FWIW: the Debian build log
(https://buildd.debian.org/status/fetch.php?pkg=postfix=amd64=3.5.6-1=1596413023=0)
shows:
make: Entering directory '/<>/src/xsasl'
gcc -fPIC -I. -I../../include -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -DDEBIAN
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
On 3/10/2021 1:55 PM, JF Mezei wrote:
On 2021-03-10 13:58, Antonio Leding wrote:
I’ve been digging into restriction lists a bit more and grinding away
on the rationale between seperating restrictions across each of the
first four lists (CLIENT, HELO, SENDER, & RECIPIENT) vs. just placing
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,
On 2021-03-10 13:58, Antonio Leding wrote:
> I’ve been digging into restriction lists a bit more and grinding away
> on the rationale between seperating restrictions across each of the
> first four lists (CLIENT, HELO, SENDER, & RECIPIENT) vs. just placing
> them all in RECIPIENT.
This is
On 3/10/2021 12:58 PM, Antonio Leding wrote:
Hello all,
I’ve been digging into restriction lists a bit more and grinding
away on the rationale between seperating restrictions across each of
the first four lists (CLIENT, HELO, SENDER, & RECIPIENT) vs. just
placing them all in RECIPIENT.
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
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
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
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.
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.
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
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
Hello all,
I’ve been digging into restriction lists a bit more and grinding away
on the rationale between seperating restrictions across each of the
first four lists (CLIENT, HELO, SENDER, & RECIPIENT) vs. just placing
them all in RECIPIENT.
Let me also state that yes, I have read the
Wietse Venema wrote:
> You could also override the timezone in main.cf:
>
> /etc/postfix/main.cf:
> # Take output from "postconf -d import_environment", then update TZ
> import_environment = TZ=whatever ...
That is a pretty interesting idea. I might do this to set TZ=UTC for here
Viktor Dukhovni wrote:
> Set your timezone consistently. When running as a non-root user, setgid
> programs such as "postqueue" ignore their environment, including TZ.
> When running as "root" they honour it.
I would have said that 100% of everything was consistently using local
time,
On Wed, Mar 10, 2021 at 04:45:29PM +0100, Markus E. wrote:
> Sorry, I meant it's empty in my config. I know that defaults to
> "permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination".
>
> But, you gave me a good hint here. I'll try to set
> smtpd_relay_restrictions to
> On Mar 10, 2021, at 1:08 PM, Wietse Venema wrote:
>
>> For machine-readable output, try "postqueue -j", which reports dates in
>> epoch time. For example:
>>
>>$ postqueue -j |
>> jq -r '[.queue_id, (.arrival_time | tostring), .sender] | join(" ")'
>
> I used this:
>
>jq -r
On Wed, 10 Mar 2021, Wietse Venema wrote:
Markus E.:
On Wed, 10 Mar 2021, Wietse Venema wrote:
Markus E.:
Hello!
I just noticed my servers replies with a 454 (instead of 554) when a bot
checks for an open relay. Here's one exameple:
Mar 10 08:53:46 mx1 postfix/smtpd[16747]: connect from
Markus E.:
> On Wed, 10 Mar 2021, Wietse Venema wrote:
>
> > Markus E.:
> >> Hello!
> >>
> >> I just noticed my servers replies with a 454 (instead of 554) when a bot
> >> checks for an open relay. Here's one exameple:
> >>
> >> Mar 10 08:53:46 mx1 postfix/smtpd[16747]: connect from
> >>
On Wed, 10 Mar 2021, Wietse Venema wrote:
Markus E.:
Hello!
I just noticed my servers replies with a 454 (instead of 554) when a bot
checks for an open relay. Here's one exameple:
Mar 10 08:53:46 mx1 postfix/smtpd[16747]: connect from
xxx.fesersglobal.com[45.85.90.xxx]
Mar 10 08:53:51 mx1
Markus E.:
> Hello!
>
> I just noticed my servers replies with a 454 (instead of 554) when a bot
> checks for an open relay. Here's one exameple:
>
> Mar 10 08:53:46 mx1 postfix/smtpd[16747]: connect from
> xxx.fesersglobal.com[45.85.90.xxx]
> Mar 10 08:53:51 mx1 postfix/smtpd[16747]: NOQUEUE:
Viktor Dukhovni:
> On Tue, Mar 09, 2021 at 11:13:37PM -0700, Bob Proulx wrote:
>
> > The time reported by mailq seems confusing. Sometimes it seems to be
> > reporting in system time and sometimes UTC time?
>
> Set your timezone consistently. When running as a non-root user, setgid
> programs
Vincent Pelletier:
> Hello,
>
> While debugging an smtp process segfault during sasl authentication
> with gmail servers in xoauth2 (xoauth2 authentication which I am in the
> process of setting up, so I have no idea if this is a recent
> regression), I discover this:
FYI, All Postfix
On Wed, 10 Mar 2021 00:31:18 +, Vincent Pelletier
wrote:
> Note how the caller (here, libkdexoauth2.so) is calling with:
> - context
> - id
> - result
> - null
> but xsasl_cyrus_client_get_passwd's signature is:
> sasl_conn_t *conn, void *context, int id, sasl_secret_t **psecret
> which
Hello!
I just noticed my servers replies with a 454 (instead of 554) when a bot
checks for an open relay. Here's one exameple:
Mar 10 08:53:46 mx1 postfix/smtpd[16747]: connect from
xxx.fesersglobal.com[45.85.90.xxx]
Mar 10 08:53:51 mx1 postfix/smtpd[16747]: NOQUEUE: reject: RCPT from
On Tue, Mar 09, 2021 at 11:13:37PM -0700, Bob Proulx wrote:
> The time reported by mailq seems confusing. Sometimes it seems to be
> reporting in system time and sometimes UTC time?
Set your timezone consistently. When running as a non-root user, setgid
programs such as "postqueue" ignore
On 09.03.21 15:26, Curtis Maurand wrote:
your a record and fqdn, your helo/ehlo hostname and the ptr record all need to
match.
that's incorrect.
IP address has to point to DNS name that maps back to the IP address.
HELO (EHLO) hostname does not necessarily need to point to that DNS name.
40 matches
Mail list logo
