postqueue -p && postsuper ageout, transfer, ...
Rok Potočnik
products which are keeping my life better and I owe a big *THANK YOU* to
all developers etc...
Now on to my questions... I'm using Postfix MTA on some email gateways
and even though I belive I've configured maximal_queue_lifetime to a
small/large enough value (2d) there's still over 1k messages in the
deferred queue.
postsuper ageout - wish:
After checking the queue using postqueue -p I've notice that a lot of
messages gets deferred (45x) instead of rejected (55x) with various
reasons, like unknown user etc... so I'd like to manually 'ageout' some
particular messages (e.g. delete the email from the queue and notify the
sender - DSN) - just deleting the email from the queue isn't an
acceptable option. I've tried to temporarily lower the
maximal_queue_lifetime and requeue the messages (postconf -e
maximal_queue_lifetime=1h; postfix reload; postsuper -r ALL; postconf -e
maximal_queue_lifetime=2d; postfix reload) but that didn't work as
expected. I belive that the best way would be to implement something
like this in postsuper, unfortunately I lack the programming skills :S
Using something like postsuper -A QUEUEID would be great
postsuper transfer - wish:
Sometimes it happens that a particular message can't be delivered to the
recipient's server either due to networking problems or something
else... I'd really like I could transfer the particular message to
another host (postsuper -T smtp:some.server.net QUEUEID). Would that
even be possible to accomplish?
and last but not least... postqueue -p and wish of printing out sender's
ip address:
I really miss a possibility of postqueue to print out client's IP
address, sometimes it would really help me out debugging some problems
and even though it would be possible to find it out using processing the
maillog for the last couple of days... but still...
Anyways, keep up the good work and hope I'm not a PITA with all this reqs.
--
BR, Rok
Jeroen Geilman
> First of all, I'm quite satisfied with Postfix and some other
> opensource products which are keeping my life better and I owe a big
> *THANK YOU* to all developers etc...
>
> Now on to my questions... I'm using Postfix MTA on some email gateways
> and even though I belive I've configured maximal_queue_lifetime to a
> small/large enough value (2d) there's still over 1k messages in the
> deferred queue.
You probably have soft_bounce enabled.
Not a good idea on a production server.
Disable it, re-queue all mail, done.
--
J.
Rok Potočnik
No that won't be it...
# postconf soft_bounce
soft_bounce = no
--
BR, Rok
Rok Potočnik
> Zitat von Rok Potočnik <r...@rula.net>:
>
>> First of all, I'm quite satisfied with Postfix and some other
>> opensource products which are keeping my life better and I owe a big
>> *THANK YOU* to all developers etc...
>>
>> Now on to my questions... I'm using Postfix MTA on some email gateways
>> and even though I belive I've configured maximal_queue_lifetime to a
>> small/large enough value (2d) there's still over 1k messages in the
>> deferred queue.
>
> undeliverable addresses...
>
> If it are mail send by your users simply let Postfix do its job and
> maybe adjust "delay_warning_time" to your needs.
>
> Regards
> Andreas
Thanks, I didn't even know that exists :S I've set it to 8h, hope it's
gonna work fine even though that messages won't be bounced.
--
BR, Rok
Jeroen Geilman
> On 26.10.2010 21:08, Jeroen Geilman wrote:
>> On 10/26/2010 09:05 PM, Rok Potočnik wrote:
>>> opensource products which are keeping my life better and I owe a big
>>> *THANK YOU* to all developers etc...
>>>
>>> Now on to my questions... I'm using Postfix MTA on some email gateways
>>> and even though I belive I've configured maximal_queue_lifetime to a
>>> small/large enough value (2d) there's still over 1k messages in the
>>> deferred queue.
>>
>> Not a good idea on a production server.
>>
>> Disable it, re-queue all mail, done.
>
> No that won't be it...
>
> # postconf soft_bounce
> soft_bounce = no
>
Then you're probably accepting way too much mail that you shouldn't, as
the other guy said.
Even with volumes exceeding 100K per day, I don't have deferred messages.
--
J.
Rok Potočnik
> Then you're probably accepting way too much mail that you shouldn't, as
> the other guy said.
> Even with volumes exceeding 100K per day, I don't have deferred messages.
ISP mail servers usually accept a large number of messages that most
company's mail servers reject (e.g. only accept only email sent from the
hosted domain). Unfortunately we can only limit the email till one
point, after that we must somehow work around the issues...
--
BR, Rok
Victor Duchovni
Arm's-length backup MX hosts, that don't know the target domain's
recipient list and don't offer the same anti-spam defense do more harm
than good. If you are an ISP that offers backup-MX services, you should
work with your clients to obtain and maintain valid recipient lists, or
work with the client to discontinue the backup MX service.
--
Viktor.
Victor Duchovni
> It's not just incoming email but outgoing as well. A lot of customers are
> using our smtp even thought we don't host their domain, either in the MUA
> directly or a smart relay on their MTA, and we also block outgoing smtp
> traffic (except the one to our servers) for customers with dynamically
> allocated IP addresses.
For outgoing mail sent by legitimate customers the right behaviour is
to queue it for a reasonable period of time (RFC recommendation is
at least 5 days, but 2 days is a not uncommon practical deviation).
Coupled with a sensible delay_warning_time (2-4 hours) on the outbound
relay, and perhaps an "smtp_fallback_relay" to keep the primary
queue uncongested, no manual intervention in the queue is warranted
or desirable.
--
Viktor.
Mark Martinec
> and last but not least... postqueue -p and wish of printing out sender's
> ip address:
> I really miss a possibility of postqueue to print out client's IP
> address, sometimes it would really help me out debugging some problems
> and even though it would be possible to find it out using processing the
> maillog for the last couple of days... but still...
Seems to me that this feature request would fit naturally into Victor's
'qshape' program (written in perl, posted here a long time ago but still
very useful). Similar to its -s option, a new option could request a
display by a log_client_address (or whatever is the most suitable
attribute).
Its current 'usage' help page:
Usage: /usr/local/bin/qshape [ -s ] [ -f ] [ -p ] [ -m <min_subdomains> ] [ -l ]
[ -b <bucket_count> ] [ -t <bucket_time> ] [ -w <terminal_width> ]
[ -N <batch_msg_count> ] [ -n <batch_top_domains> ]
[ -c <config_directory> ] [ <queue_name> ... ]
The 's' option shows sender domain counts.
The 'f' option uses a content filter as the recipient domain.
The 'p' option shows address counts by for parent domains.
Parent domains are shown with a leading '.' before the domain name.
Parent domains are only shown if the the domain is not a TLD, and at
least <min_subdomains> (default 5) subdomains are shown in the output.
The bucket age ranges in units of <bucket_time> minutes are
[0,1), [1,2), [2,4), [4,8), [8, 16), ... i.e.:
the first bucket is [0, bucket_time) minutes
the second bucket is [bucket_time, 2*bucket_time) minutes
the third bucket is [2*bucket_time, 4*bucket_time) minutes...
'-l' makes the ages linear, the number of buckets shown is <bucket_count>
The default summary is for the incoming and active queues. An explicit
list of queue names can be given on the command line. Non-absolute queue
names are interpreted relative to the Postfix queue directory. Use
<config_directory> to specify a non-default Postfix instance. Values of
the main.cf queue_directory parameter that use variable expansions are
not supported. If necessary, use explicit absolute paths for all queues.
Mark
Victor Duchovni
> Rok Poto??nik writes:
> > and last but not least... postqueue -p and wish of printing out sender's
> > ip address:
> > I really miss a possibility of postqueue to print out client's IP
> > address, sometimes it would really help me out debugging some problems
> > and even though it would be possible to find it out using processing the
> > maillog for the last couple of days... but still...
>
> Seems to me that this feature request would fit naturally into Victor's
> 'qshape' program (written in perl, posted here a long time ago but still
> very useful). Similar to its -s option, a new option could request a
> display by a log_client_address (or whatever is the most suitable
> attribute).
I have not needed this filter, but it is not an unnatural enhancement.
Anyone want to contribute a code/documentation update?
Probably the option argument should be a CIDR mask for aggregating client
IPs, with an optional prefix to match. So that one can get a feel for
the volume aggregated on /28 or /24 boundaries, before zooming in on
sub-block of interest.
--
Viktor.
Rok Potočnik
> Rok Potočnik writes:
>> and last but not least... postqueue -p and wish of printing out sender's
>> ip address:
>> I really miss a possibility of postqueue to print out client's IP
>> address, sometimes it would really help me out debugging some problems
>> and even though it would be possible to find it out using processing the
>> maillog for the last couple of days... but still...
>
> Seems to me that this feature request would fit naturally into Victor's
> 'qshape' program (written in perl, posted here a long time ago but still
> very useful). Similar to its -s option, a new option could request a
> display by a log_client_address (or whatever is the most suitable
> attribute).
>
>
> Usage: /usr/local/bin/qshape [ -s ] [ -f ] [ -p ] [ -m<min_subdomains> ] [ -l ]
> [ -b<bucket_count> ] [ -t<bucket_time> ] [ -w<terminal_width> ]
> [ -N<batch_msg_count> ] [ -n<batch_top_domains> ]
> [ -c<config_directory> ] [<queue_name> ... ]
> The 's' option shows sender domain counts.
> The 'f' option uses a content filter as the recipient domain.
> The 'p' option shows address counts by for parent domains.
> Parent domains are shown with a leading '.' before the domain name.
> Parent domains are only shown if the the domain is not a TLD, and at
> least<min_subdomains> (default 5) subdomains are shown in the output.
>
> The bucket age ranges in units of<bucket_time> minutes are
> [0,1), [1,2), [2,4), [4,8), [8, 16), ... i.e.:
> the first bucket is [0, bucket_time) minutes
> the second bucket is [bucket_time, 2*bucket_time) minutes
> the third bucket is [2*bucket_time, 4*bucket_time) minutes...
> '-l' makes the ages linear, the number of buckets shown is<bucket_count>
>
> The default summary is for the incoming and active queues. An explicit
> list of queue names can be given on the command line. Non-absolute queue
> names are interpreted relative to the Postfix queue directory. Use
> <config_directory> to specify a non-default Postfix instance. Values of
> the main.cf queue_directory parameter that use variable expansions are
> not supported. If necessary, use explicit absolute paths for all queues.
Mark, even though qshape gives some excellent statistical information
about queue usage it lacks the most important thing I'd need - queue id
of each 'sender IP' email.
Your proposal would expose client's IP address that sends the most
deferred messages, but afterwards I should still parse the log file. I
belive the best solution would be if both postqueue -p *and* qshape
would provide me with client's IP...
--
BR, Rok
Victor Duchovni
>> The default summary is for the incoming and active queues. An explicit
>> list of queue names can be given on the command line. Non-absolute queue
>> names are interpreted relative to the Postfix queue directory. Use
>> <config_directory> to specify a non-default Postfix instance. Values of
>> the main.cf queue_directory parameter that use variable expansions are
>> not supported. If necessary, use explicit absolute paths for all queues.
>
> Mark, even though qshape gives some excellent statistical information about
> queue usage it lacks the most important thing I'd need - queue id of each
> 'sender IP' email.
> Your proposal would expose client's IP address that sends the most deferred
> messages, but afterwards I should still parse the log file. I belive the
> best solution would be if both postqueue -p *and* qshape would provide me
> with client's IP...
Wshape was designed to provide aggregate, not per-message data, so that
one can get a feel for the health of the queue.
The qshape utility is a relatively easy to understand short Perl
script. Feel free to reshape into a tool that meets your needs. The
only downside is that if the Postfix queue-file format changes, and
you have a custom "qshape", you have to port it to the new format.
--
Viktor.