Fun and profit with mailq
The man page on sendmail contains a small section on mailq which explains the display o family. While the postqueue man page says that postqueue -p implements the mailq command vi shows(). The only mention of 'hold' on either of these man pages is in the description of the mailq/postqueue -p output status character '!'. (This is all just background to show that yes, I have dug into the man pages). What I would like to do is to execute a command that only returns output if there are messages on hold in the mailq and am wondering if there is a better way than $(mailq | grep '!') to do this. -- "Thank you for sending me a copy of your book; I'll waste no time reading it." - Moses Hadas
Re: Fun and profit with mailq
On 2022 Feb 16, at 05:06, @lbutlr wrote: > What I would like to do is to execute a command that only returns output if > there are messages on hold On a related question, is there a way to tell postfix "put all outbound mail into the hold queue" so I can test some of this? I know postsuper -h ALL will put all messages currently in the queue on hold for a few minutes? queue_run_delay looked promising, but it only applies once a message is already in the queue. It'd ne great if I could just hold every message and then let it clear on the queue_run_delay=60 interval for testing. No one is even going to notice 1 minute in the queue. -- "Last night - you were unhinged. You were like some desperate, howling demon. You frightened me. - Do it again!"
AW: Fun and profit with mailq
Don´t know what exactly you are trying to do, but to monitor the queue, I use postqueue -j (for json). Forcing some messages to remain in the queue is easy: just define a transport policy like dane-only for a destination that does not support dane. -- Joachim -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org Im Auftrag von @lbutlr Gesendet: Wednesday, 16 February 2022 13:36 An: postfix-users@postfix.org Betreff: Re: Fun and profit with mailq On 2022 Feb 16, at 05:06, @lbutlr wrote: > What I would like to do is to execute a command that only returns output if > there are messages on hold On a related question, is there a way to tell postfix "put all outbound mail into the hold queue" so I can test some of this? I know postsuper -h ALL will put all messages currently in the queue on hold for a few minutes? queue_run_delay looked promising, but it only applies once a message is already in the queue. It'd ne great if I could just hold every message and then let it clear on the queue_run_delay=60 interval for testing. No one is even going to notice 1 minute in the queue. -- "Last night - you were unhinged. You were like some desperate, howling demon. You frightened me. - Do it again!"
Re: AW: Fun and profit with mailq
A cleaner solution for queueing messages is putting them on a disabled smtp service, but the OP meant how to HOLD them.Look at the ACCESS readme for examples.Op 16 feb. 2022 13:43 schreef Joachim Lindenberg :Don´t know what exactly you are trying to do, but to monitor the queue, I use postqueue -j (for json). Forcing some messages to remain in the queue is easy: just define a transport policy like dane-only for a destination that does not support dane. -- Joachim -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org Im Auftrag von @lbutlr Gesendet: Wednesday, 16 February 2022 13:36 An: postfix-users@postfix.org Betreff: Re: Fun and profit with mailq On 2022 Feb 16, at 05:06, @lbutlr wrote: > What I would like to do is to execute a command that only returns output if there are messages on hold On a related question, is there a way to tell postfix "put all outbound mail into the hold queue" so I can test some of this? I know postsuper -h ALL will put all messages currently in the queue on hold for a few minutes? queue_run_delay looked promising, but it only applies once a message is already in the queue. It'd ne great if I could just hold every message and then let it clear on the queue_run_delay=60 interval for testing. No one is even going to notice 1 minute in the queue. -- "Last night - you were unhinged. You were like some desperate, howling demon. You frightened me. - Do it again!"
Re: Fun and profit with mailq
There is an example in the pistsuper manpage that uses "postqueue -j | jq" to select messages, and to feed a list of queue IDS into the postsuper command. Untested example: postqueue -j | jq -r ' # See JSON OBJECT FORMAT section in the postqueue(1) manpage select(.queue_name == "deferred") | .queue_id ' | postsuper -h - Wietse
Re: Fun and profit with mailq
Wietse Venema: > There is an example in the pistsuper manpage that uses "postqueue > -j | jq" to select messages, and to feed a list of queue IDS into > the postsuper command. > > Untested example: > > postqueue -j | jq -r ' > # See JSON OBJECT FORMAT section in the postqueue(1) manpage > select(.queue_name == "deferred") > | .queue_id >' | postsuper -h - And "postsuper -h ALL deferred" might do the same thing. Wietse
Re: Fun and profit with mailq
On 16 Feb 2022, at 8:16 am, Wietse Venema wrote:
> postqueue -j | jq -r '
> # See JSON OBJECT FORMAT section in the postqueue(1) manpage
> select(.queue_name == "deferred")
> | .queue_id
> ' | postsuper -h -
While we're on the topic of JSON output, FWIW, I am not convinced that
the recent change to protect downstream consumers of JSON from
non-printable content in "postqueue -j" output (which is robustly
escaped in its JSON representation) was the right choice.
20211027
Safety: the postqueue command now sanitizes strings before they
are formatted as json output or legacy output. These outputs are
piped into other programs that are run by administrative
users. This closes a hypothetical opportunity for privilege
escalation. Files: util/attr.h, util/attr_scan*.c,
postqueue/showq_json.c, postqueue/showq_compat.c.
IMHO any responsibility to handle unexpected string payloads falls
squarely on the JSON consumer, not showq(8) or postqueue(1). Sure, use
of "jq -r" exposes unescaped output and the user should be warned to
expect the unexpected.
Alternatively, perhaps there should be an option to turn off the safety
net. Something like the '-J' option below (with appropriate
documentation and warnings).
--
Viktor.
diff --git a/src/postqueue/postqueue.c b/src/postqueue/postqueue.c
index 09e5bcaf8..7bad79d2e 100644
--- a/src/postqueue/postqueue.c
+++ b/src/postqueue/postqueue.c
@@ -323,6 +323,7 @@
#define PQ_MODE_FLUSH_SITE 3 /* flush site */
#define PQ_MODE_FLUSH_FILE 4 /* flush message */
#define PQ_MODE_JSON_LIST 5 /* JSON-format queue listing */
+#define PQ_MODE_JSON_RAW 6 /* JSON-format queue listing (raw) */
/*
* Silly little macros (SLMs).
@@ -341,6 +342,9 @@ static const CONFIG_STR_TABLE str_table[] = {
0,
};
+#define RAW_JSON 0
+#define SANITISED_JSON 1
+
/* showq_client - run the appropriate showq protocol client */
static void showq_client(int mode, VSTREAM *showq)
@@ -354,7 +358,10 @@ static void showq_client(int mode, VSTREAM *showq)
showq_compat(showq);
break;
case PQ_MODE_JSON_LIST:
- showq_json(showq);
+ showq_json(showq, SANITISED_JSON);
+ break;
+case PQ_MODE_JSON_RAW:
+ showq_json(showq, RAW_JSON);
break;
default:
msg_panic("show_queue: unknown mode %d", mode);
@@ -605,7 +612,7 @@ int main(int argc, char **argv)
* mail configuration read routine. Don't do complex things until we have
* completed initializations.
*/
-while ((c = GETOPT(argc, argv, "c:fi:jps:v")) > 0) {
+while ((c = GETOPT(argc, argv, "c:fi:jJps:v")) > 0) {
switch (c) {
case 'c': /* non-default configuration */
if (setenv(CONF_ENV_PATH, optarg, 1) < 0)
@@ -627,6 +634,11 @@ int main(int argc, char **argv)
usage();
mode = PQ_MODE_JSON_LIST;
break;
+ case 'J':
+ if (mode != PQ_MODE_DEFAULT)
+ usage();
+ mode = PQ_MODE_JSON_RAW;
+ break;
case 'p': /* traditional mailq */
if (mode != PQ_MODE_DEFAULT)
usage();
@@ -705,6 +717,7 @@ int main(int argc, char **argv)
/* NOTREACHED */
case PQ_MODE_MAILQ_LIST:
case PQ_MODE_JSON_LIST:
+case PQ_MODE_JSON_RAW:
show_queue(mode);
exit(0);
break;
diff --git a/src/postqueue/showq_json.c b/src/postqueue/showq_json.c
index fc205c726..f2e60f622 100644
--- a/src/postqueue/showq_json.c
+++ b/src/postqueue/showq_json.c
@@ -123,7 +123,7 @@ static char *json_quote(VSTRING *result, const char *text)
/* json_message - report status for one message */
-static void format_json(VSTREAM *showq_stream)
+static void format_json(VSTREAM *showq_stream, int sanitise)
{
static VSTRING *queue_name = 0;
static VSTRING *queue_id = 0;
@@ -151,7 +151,7 @@ static void format_json(VSTREAM *showq_stream)
* Read the message properties and sender address.
*/
if (attr_scan(showq_stream, ATTR_FLAG_MORE | ATTR_FLAG_STRICT
- | ATTR_FLAG_PRINTABLE,
+ | (sanitise ? ATTR_FLAG_PRINTABLE : 0),
RECV_ATTR_STR(MAIL_ATTR_QUEUE, queue_name),
RECV_ATTR_STR(MAIL_ATTR_QUEUEID, queue_id),
RECV_ATTR_LONG(MAIL_ATTR_TIME, &arrival_time),
@@ -204,7 +204,7 @@ static void format_json(VSTREAM *showq_stream)
/* showq_json - streaming JSON-format output adapter */
-voidshowq_json(VSTREAM *showq_stream)
+voidshowq_json(VSTREAM *showq_stream, int sanitise)
{
int showq_status;
@@ -214,7 +214,7 @@ voidshowq_json(VSTREAM *showq_stream)
*/
while ((showq_status = attr_scan_more(showq_stream)) > 0
&& vstream_ferror(VSTREAM_OUT) == 0) {
- format_json(showq_stream);
+ format_json(showq_
Re: Fun and profit with mailq
Viktor Dukhovni: > On 16 Feb 2022, at 8:16 am, Wietse Venema wrote: > > > postqueue -j | jq -r ' > > # See JSON OBJECT FORMAT section in the postqueue(1) manpage > > select(.queue_name == "deferred") > > | .queue_id > > ' | postsuper -h - > > While we're on the topic of JSON output, FWIW, I am not convinced that > the recent change to protect downstream consumers of JSON from > non-printable content in "postqueue -j" output (which is robustly > escaped in its JSON representation) was the right choice. > > 20211027 > >Safety: the postqueue command now sanitizes strings before they >are formatted as json output or legacy output. These outputs are >piped into other programs that are run by administrative >users. This closes a hypothetical opportunity for privilege >escalation. Files: util/attr.h, util/attr_scan*.c, >postqueue/showq_json.c, postqueue/showq_compat.c. > > IMHO any responsibility to handle unexpected string payloads falls > squarely on the JSON consumer, not showq(8) or postqueue(1). Sure, use > of "jq -r" exposes unescaped output and the user should be warned to > expect the unexpected. > > Alternatively, perhaps there should be an option to turn off the safety > net. Something like the '-J' option below (with appropriate > documentation and warnings). And what about non-json output? Wietse
Re: Fun and profit with mailq
On Wed, Feb 16, 2022 at 09:42:51AM -0500, Wietse Venema wrote: > > Alternatively, perhaps there should be an option to turn off the safety > > net. Something like the '-J' option below (with appropriate > > documentation and warnings). > > And what about non-json output? My view of "postqueue -p" is that it is eyeball-readable and not machine-readable, and that sanitisation is appropriate to preserve the visual structure of the output. Users who want an unsanitised form of the queue content should consume JSON. -- Viktor.
Re: Fun and profit with mailq
On 2022 Feb 16, at 06:37, Wietse Venema wrote: > Wietse Venema: >> There is an example in the pistsuper manpage that uses "postqueue >> -j | jq" to select messages, and to feed a list of queue IDS into >> the postsuper command. >> >> Untested example: >> >> postqueue -j | jq -r ' >> # See JSON OBJECT FORMAT section in the postqueue(1) manpage >> select(.queue_name == "deferred") >> | .queue_id >> ' | postsuper -h - > > And "postsuper -h ALL deferred" might do the same thing. This will only hold messages that are already deferred in the queue, right. I still need so modify main.cf to redirect the messages to get deferred. -- I loved you when our love was blessed I love you now there's nothing left But sorrow and a sense of overtime
Re: Fun and profit with mailq
Viktor Dukhovni: > On Wed, Feb 16, 2022 at 09:42:51AM -0500, Wietse Venema wrote: > > > > Alternatively, perhaps there should be an option to turn off the safety > > > net. Something like the '-J' option below (with appropriate > > > documentation and warnings). > > > > And what about non-json output? > > My view of "postqueue -p" is that it is eyeball-readable and not > machine-readable, and that sanitisation is appropriate to preserve the > visual structure of the output. It's not only eyeballs. There are 20 years of examples with mailq|awk. This is where embedded newlines etc. could do damage, and there should be no option to unsanitize that output. > Users who want an unsanitised form of the queue content should > consume JSON. Unsanitized but json-escaped. If people want to unescape that, then they have to write extra code, so 'unsanitized' would still be safe for naive scripts. I think I missed that "jq -r" output is still json-escaped. In that light, is there any need for 3.7-style sanitization of json output? We could still revert that early in 3.7.1; I doubt that this would break things already. Wietse
Re: Fun and profit with mailq
On 2/16/2022 10:35 AM, @lbutlr wrote: On 2022 Feb 16, at 06:37, Wietse Venema wrote: Wietse Venema: There is an example in the pistsuper manpage that uses "postqueue -j | jq" to select messages, and to feed a list of queue IDS into the postsuper command. Untested example: postqueue -j | jq -r ' # See JSON OBJECT FORMAT section in the postqueue(1) manpage select(.queue_name == "deferred") | .queue_id ' | postsuper -h - And "postsuper -h ALL deferred" might do the same thing. This will only hold messages that are already deferred in the queue, right. I still need so modify main.cf to redirect the messages to get deferred. To put everything on hold, insert check_client_access static:hold in one of your restrictions. Something like: smtpd_client_restrictions = check_client_access static:hold ... stuff you have already ... -- Noel Jones
Re: Fun and profit with mailq
On 2022 Feb 16, at 07:49, Viktor Dukhovni wrote: > Users who want an unsanitised form of the queue content should consume > JSON. This is why I need actual messages in the hold queue so I can test. I do prefer -j if for nothing else that it returns nothing at all when the queue is empty while -o returns "The mail queue is empty" (or something like that). -- I loved you when our love was blessed I love you now there's nothing left But sorrow and a sense of overtime
Re: Fun and profit with mailq
On 2022 Feb 16, at 09:44, Noel Jones wrote: > To put everything on hold, insert check_client_access static:hold in one of > your restrictions. Something like: > > smtpd_client_restrictions = > check_client_access static:hold > ... stuff you have already ... Thanks, this is perfect. Will start testing tonight when this will have less impact. -- I loved you when our love was blessed I love you now there's nothing left But sorrow and a sense of overtime
Re: Fun and profit with mailq
> On 16 Feb 2022, at 11:43 am, Wietse Venema wrote: > >> Users who want an unsanitised form of the queue content should >> consume JSON. > > Unsanitized but json-escaped. If people want to unescape that, then > they have to write extra code, so 'unsanitized' would still be safe > for naive scripts. When represented as JSON. > I think I missed that "jq -r" output is still json-escaped. In that > light, is there any need for 3.7-style sanitization of json output? > We could still revert that early in 3.7.1; I doubt that this would > break things already. Actually, no, with "-r" not only are quotes removed, but also escaped forms are converted back to the underlying UTF-8 form, and control characters are output verbatim (as newlines, ESC, ...). -- Viktor.
Re: Fun and profit with mailq
On Wed, Feb 16, 2022 at 12:09:24PM -0500, Viktor Dukhovni wrote: > > I think I missed that "jq -r" output is still json-escaped. In that > > light, is there any need for 3.7-style sanitization of json output? > > We could still revert that early in 3.7.1; I doubt that this would > > break things already. > > Actually, no, with "-r" not only are quotes removed, but also escaped > forms are converted back to the underlying UTF-8 form, and control > characters are output verbatim (as newlines, ESC, ...). Example: $ printf "%s\n" '"foo\nbar\nbaz"' "foo\nbar\nbaz" $ printf "%s\n" '"foo\nbar\nbaz"' | jq -r foo bar baz -- Viktor.
Re: Fun and profit with mailq
Viktor Dukhovni:
> > On 16 Feb 2022, at 11:43 am, Wietse Venema wrote:
> >
> >> Users who want an unsanitised form of the queue content should
> >> consume JSON.
> >
> > Unsanitized but json-escaped. If people want to unescape that, then
> > they have to write extra code, so 'unsanitized' would still be safe
> > for naive scripts.
>
> When represented as JSON.
>
> > I think I missed that "jq -r" output is still json-escaped. In that
> > light, is there any need for 3.7-style sanitization of json output?
> > We could still revert that early in 3.7.1; I doubt that this would
> > break things already.
>
> Actually, no, with "-r" not only are quotes removed, but also escaped
> forms are converted back to the underlying UTF-8 form, and control
> characters are output verbatim (as newlines, ESC, ...).
Oops, I did an incorrect experiment.
Confirming that -r produces unescaped output:
$ cat x
{ "foo": "\nbar"}
$ jq -r .foo x|od -cb
000 \n b a r \n
012 142 141 162 012
So, "jq -r" expands \n into newline. What is the legitimate need
to pass such things into scripts that expect newline-delimited output?
Wietse
Re: Fun and profit with mailq
> On 16 Feb 2022, at 1:20 pm, Wietse Venema wrote:
>
>> Actually, no, with "-r" not only are quotes removed, but also escaped
>> forms are converted back to the underlying UTF-8 form, and control
>> characters are output verbatim (as newlines, ESC, ...).
>
> Oops, I did an incorrect experiment.
>
> Confirming that -r produces unescaped output:
>
>$ cat x
>{ "foo": "\nbar"}
>$ jq -r .foo x|od -cb
>000 \n b a r \n
>012 142 141 162 012
>
> So, "jq -r" expands \n into newline. What is the legitimate need
> to pass such things into scripts that expect newline-delimited output?
Well, if a message contains non-printable characters in the sender,
one of the recipient addresses, or delay reason, and I process the
output of "postqueue -j" in a language that supports JSON ("jq",
"python", "perl", ...) then it should be possible to see the actual
data without sanitisation.
--
Viktor.
Re: Fun and profit with mailq
Viktor Dukhovni:
> > On 16 Feb 2022, at 1:20 pm, Wietse Venema wrote:
> >
> >> Actually, no, with "-r" not only are quotes removed, but also escaped
> >> forms are converted back to the underlying UTF-8 form, and control
> >> characters are output verbatim (as newlines, ESC, ...).
> >
> > Oops, I did an incorrect experiment.
> >
> > Confirming that -r produces unescaped output:
> >
> >$ cat x
> >{ "foo": "\nbar"}
> >$ jq -r .foo x|od -cb
> >000 \n b a r \n
> >012 142 141 162 012
> >
> > So, "jq -r" expands \n into newline. What is the legitimate need
> > to pass such things into scripts that expect newline-delimited output?
>
> Well, if a message contains non-printable characters in the sender,
> one of the recipient addresses, or delay reason, and I process the
> output of "postqueue -j" in a language that supports JSON ("jq",
> "python", "perl", ...) then it should be possible to see the actual
> data without sanitisation.
Then we can ad a -R option that disables filtering (make then do
something extra) with a warning. Will this be necessary for Postfix
3.7? Probably, so that we don't have too much difference between
examples of how to do things.
The threat model is that an attacker can compromise a process with
user "postfix" privileges and subvert the showq daemon or the content
of queue files. The showq daemon is supposed to ignore bogus queue
IDs, bogus queue names, and non-files.
Or, that some well-meaning moron changes Postfix to preserve newlines
in, for example, responses from remote SMTP servers.
Either way, that would subvert text-based postqueue|whatever|postsuper
pipelines that typically run as root.
Wietse
Re: Fun and profit with mailq
Wietse Venema:
> Viktor Dukhovni:
> > > On 16 Feb 2022, at 1:20 pm, Wietse Venema wrote:
> > >
> > >> Actually, no, with "-r" not only are quotes removed, but also escaped
> > >> forms are converted back to the underlying UTF-8 form, and control
> > >> characters are output verbatim (as newlines, ESC, ...).
> > >
> > > Oops, I did an incorrect experiment.
> > >
> > > Confirming that -r produces unescaped output:
> > >
> > >$ cat x
> > >{ "foo": "\nbar"}
> > >$ jq -r .foo x|od -cb
> > >000 \n b a r \n
> > >012 142 141 162 012
> > >
> > > So, "jq -r" expands \n into newline. What is the legitimate need
> > > to pass such things into scripts that expect newline-delimited output?
> >
> > Well, if a message contains non-printable characters in the sender,
> > one of the recipient addresses, or delay reason, and I process the
> > output of "postqueue -j" in a language that supports JSON ("jq",
> > "python", "perl", ...) then it should be possible to see the actual
> > data without sanitisation.
Then we can ad a -R option that disables filtering (make then do
something extra) with a warning. Will this be necessary for Postfix
Clarification: With a warning in the documentation for that option.
3.7? Probably, so that we don't have too much difference between
examples of how to do things.
The threat model is that an attacker can compromise a process with
user "postfix" privileges and subvert the showq daemon or the content
of queue files. The showq daemon is supposed to ignore bogus queue
IDs, bogus queue names, and non-files.
Or, that some well-meaning moron changes Postfix to preserve newlines
in, for example, responses from remote SMTP servers.
Either way, that would subvert text-based postqueue|whatever|postsuper
pipelines that typically run as root.
Wietse
Re: Fun and profit with mailq
On Wed, Feb 16, 2022 at 02:15:31PM -0500, Wietse Venema wrote:
> > Well, if a message contains non-printable characters in the sender,
> > one of the recipient addresses, or delay reason, and I process the
> > output of "postqueue -j" in a language that supports JSON ("jq",
> > "python", "perl", ...) then it should be possible to see the actual
> > data without sanitisation.
>
> Then we can ad a -R option that disables filtering (make then do
> something extra) with a warning. Will this be necessary for Postfix
> 3.7? Probably, so that we don't have too much difference between
> examples of how to do things.
Sure, it would be a reasonably small backwards-compatible addition.
> The threat model is that an attacker can compromise a process with
> user "postfix" privileges and subvert the showq daemon or the content
> of queue files. The showq daemon is supposed to ignore bogus queue
> IDs, bogus queue names, and non-files.
Right, it is important to stress in documentation and exampels of the
use of such a feature that "postqueue -J" or be it "postqueue -R -j"
output is *untrusted* (tainted) and use of the data by e.g. "root" needs
to exercise caution.
> Or, that some well-meaning moron changes Postfix to preserve newlines
> in, for example, responses from remote SMTP servers.
Are we sure that presently, even without sanitisation there are no
valid cases in which the output of "postqueue -j" would contain
strings with non-printable content?
Can Postfix accept (without mangling) (with representing
the underlying character) any of:
Server:
MAIL FROM:<"foo+\bar"@example.com>
RCPT TO:<"foo+\bar"@example.com>
Client:
450 4.0.0 You won't our filters
[ IIRC multi-line responses get merged into a single line in the SMTP
client, but I'm not sure, and haven't checked just now. ]
> Either way, that would subvert text-based postqueue|whatever|postsuper
> pipelines that typically run as root.
Yes. Unsanitised untrusted input and root mix poorly.
--
Viktor.
Re: Fun and profit with mailq
Viktor Dukhovni: > Are we sure that presently, even without sanitisation there are no > valid cases in which the output of "postqueue -j" would contain > strings with non-printable content? Definitely no newlines. Because those change the structure of text. > Can Postfix accept (without mangling) (with representing > the underlying character) any of: > > Server: > MAIL FROM:<"foo+\bar"@example.com> > RCPT TO:<"foo+\bar"@example.com> Accepted, and preserved in SMTP/LMTP or mailbox delivery, but it won't reach postqueue. There is a mandatory printable() filter in the bounce daemon after it reads a request, before it writes the bounce/defer/etc log (look for the VS_NEUTER macro). ESC does not count as a printable character. So that makes this discussion moot as far as postqueue is concerned. All *legitimate* content in a bounce/defer/etc log has gone through printable(). There really is no reason to disable the printable() call on the postqueue side, because it is supposed to be a noop; in the cases where it is not a noop, the queue file contains content that should not have been there. > Client: > 450 4.0.0 You won't our filters Filtered out as Postfix reads remote SMTP server responses. There is also a mandatory filter for Postfix responses to a remote SMTP client, when writing to the mail log, when reading pipe-to-command responses. Wietse
Re: Fun and profit with mailq
> On 16 Feb 2022, at 3:49 pm, Wietse Venema wrote: > >> Can Postfix accept (without mangling) (with representing >> the underlying character) any of: >> >>Server: >>MAIL FROM:<"foo+\bar"@example.com> >>RCPT TO:<"foo+\bar"@example.com> > > Accepted, and preserved in SMTP/LMTP or mailbox delivery, but it > won't reach postqueue. So presumably the envelope sender and recipient addresses in the queue file can hold non-printable characters. > There is a mandatory printable() filter in the bounce daemon after > it reads a request, before it writes the bounce/defer/etc log (look > for the VS_NEUTER macro). ESC does not count as a printable character. Are envelope addresses censored (sanitised) by showq(8)? -- Viktor.
Re: Fun and profit with mailq
On Wed, Feb 16, 2022 at 05:05:39PM -0500, Viktor Dukhovni wrote: > > There is a mandatory printable() filter in the bounce daemon after > > it reads a request, before it writes the bounce/defer/etc log (look > > for the VS_NEUTER macro). ESC does not count as a printable character. > > Are envelope addresses censored (sanitised) by showq(8)? I seems they are: src/showq/showq.c: ... case REC_TYPE_FROM: ... quote_822_local(printable_quoted_addr, start); printable(STR(printable_quoted_addr), '?'); ... case REC_TYPE_RCPT: ... quote_822_local(printable_quoted_addr, start); printable(STR(printable_quoted_addr), '?'); So unless that's "relaxed", with the responsibility moved to postqueue(1), relaxing the rules in "postqueue" is perhaps futile. -- Viktor.
Re: Fun and profit with mailq
Viktor Dukhovni: > > > > On 16 Feb 2022, at 3:49 pm, Wietse Venema wrote: > > > >> Can Postfix accept (without mangling) (with representing > >> the underlying character) any of: > >> > >>Server: > >>MAIL FROM:<"foo+\bar"@example.com> > >>RCPT TO:<"foo+\bar"@example.com> > > > > Accepted, and preserved in SMTP/LMTP or mailbox delivery, but it > > won't reach postqueue. > > So presumably the envelope sender and recipient addresses in > the queue file can hold non-printable characters. Except for newline. Postfix also does not filter javascript in HTML tage in an email address, which might be a greater threat than escape characters. > > There is a mandatory printable() filter in the bounce daemon after > > it reads a request, before it writes the bounce/defer/etc log (look > > for the VS_NEUTER macro). ESC does not count as a printable character. > > Are envelope addresses censored (sanitised) by showq(8)? That would be the wrong place. Non-printable characters are censored in the bounce daemon as it writes the bounce/defer/etc log, and in the postqueue comamnd as it exports to a non-Postfix environment. Wietse
Need help with smtp_tls_policy_maps settings.
Hi, Cannot receive email from ansmtp.ariba.com[216.109.104.12] The following error is in the log. --- start -- Feb 14 18:26:22 mail postfix/smtpd[210806]: SSL_accept:SSLv3/TLS write server done Feb 14 18:26:22 mail postfix/smtpd[210806]: SSL_accept:error in SSLv3/TLS write server done Feb 14 18:26:22 mail postfix/smtpd[210806]: SSL_accept error from ansmtp.ariba.com[216.109.104.12]: Connection reset by peer Feb 14 18:26:22 mail postfix/smtpd[210806]: lost connection after STARTTLS from ansmtp.ariba.com[216.109.104.12] end --- Assuming the error is on their end and so decided to use smtp_tls_policy_maps to set tls_security_level for that domain to none. -- start --- smtpd_tls_security_level = may smtp_tls_policy_maps = hash:/etc/postfix/tls_policy tls_policy .ariba.com none match=.ariba.com:ariba.com - end - Did postmap tls_policy and got tls_policy.db Postfix: 3.5.8 (rocky linux 8.5) Even when .ariba.com is set to none, TLS is still initiated. If smtpd_tls_security_level = none then TLS is not used. But then all domains will not use TLS. Was the setting correct? Is there any other settings that need to be done. P.V.Anthony
