Eaten by a Grue's questions

I have sender_bcc_maps set up and working with postfix so that outgoing mail gets bcc'd to the sender's address. My configuration is more or less:

main.cf

sender_bcc_maps = regexp:/etc/postfix/regexp_sender_bcc

regexp_sender_bcc

/^([^@]+)@[a-zA-Z0-9_]+\.[a-zA-Z0-9_]+$/ [email protected]

This works great. Now I have an email address [email protected] that I'd like to exclude from this configuration.

Idea 1: I first tried adding a row to route to a non-existent mailbox

/^nobody.*$/ [email protected]

Predictably, this results in an attempt to bcc that address and a bounceback since it doesn't exist.

Idea 2: Next I tried simply changing the target to an empty string:

/^nobody.*$/

This generates a warning and completely drops the outgoing mail as well:

warning: sender_bcc_maps lookup of [email protected] returns an empty string result
warning: sender_bcc_maps should return NO RESULT in case of NOT FOUND
warning: sender_bcc_maps map lookup problem -- message not accepted, try again later

Idea 3: I then tried routing this mail to a local user:

/^nobody.*$/ nobody@localhost

This somewhat does the job but then all these messages are still delivered to the local mail system.

I'd like to do either one of these - preferring the former:

• configure sender_bcc_maps to completely ignore a specific sender's address
• configure postfix to completely discard mail to a specific user

My question is very similar to this unanswered question: Apache 2.4 + PHP-FPM + Chromelogger (how to increase HTTP header length limit?)

Initially I was getting:

[proxy_fcgi:error] Premature end of script headers

Then after disabling the proxy:

[cgi:error] Premature end of script headers: ea-php74

I am sending debugging data in the response headers and these errors are generated any time I send response headers around 8K or more. Seems somewhere along the way the headers are being truncated.

I've read about adjusting LimitRequestFieldSize to no avail as this setting limits only request header length, not response headers.

Is this due to PHP or Apache? Is there a setting to limit the maximum allowed response header size?

I'm running Ubuntu 20.04 / OpenSSH_8.2p1 and have a client trying to connect but it's failing with error in auth.log like:

Nov 25 02:13:20 sshd[517621]: ssh_dispatch_run_fatal: Connection from 192.0.2.1 port 50127: DH GEX group out of range [preauth]

I did see a few other questions asking about this error:

https://serverfault.com/questions/786587/dh-gex-group-out-of-range/809082
https://serverfault.com/questions/729033/ssh-dh-gex-group-out-of-range
https://serverfault.com/questions/852666/sftp-connection-fails-with-dh-gex-group-out-of-range
https://serverfault.com/questions/920839/ssh-error-ssh-dispatch-run-fatal-connection-to-192-168-x-x-port-22-dh-gex-gro

But all of those questions relate to someone with a newer client trying to connect to an older server and receiving the error on the client end. The best solution in this case is probably to upgrade the client. In my case however, I have no control over the client and since I'm running a very new version, my assumption is that this has to do with the server version being newer than the client.

I'd like our server to accept their connections. Is there a directive I can adjust in /etc/ssh/sshd_config to allow older clients to connect? Or any other solution that doesn't involve asking the client to upgrade their version?

I"m a bit confused about the activity in my mail server logs (addresses and destination redacted for privacy):

Nov  1 21:00:03 mail postfix/smtp[745742]: Trusted TLS connection established to mx.example.com[192.0.2.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:10 mail postfix/smtp[745742]: 0C1551DC073: to=<[email protected]>, relay=mx.example.com[192.0.2.1]:25, delay=7.3, delays=0.01/0.01/0.42/6.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 7E42A921A9A25)
Nov  1 21:00:11 mail postfix/smtp[745829]: Trusted TLS connection established to mx.example.com[192.0.2.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:18 mail postfix/smtp[745829]: 903371DC08B: host mx.example.com[192.0.2.1] said: 451 4.7.1 Greylisting in action, please come back later (in reply to end of DATA command)
Nov  1 21:00:18 mail postfix/smtp[745829]: Trusted TLS connection established to mx.example.net[192.0.2.2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:25 mail postfix/smtp[745829]: 903371DC08B: to=<[email protected]>, relay=mx.example.net[192.0.2.2]:25, delay=16, delays=0.01/1.4/7.7/7.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BB99F922EC625)

It appears postfix got a greylist response on the second mail to the domain in question but then immediately re-attempted delivery to a different MX record ip (@21:00:18)? Am I misunderstanding what's going on here?

All settings are more or less default with these exceptions:

minimal_backoff_time = 180s
maximal_backoff_time = 3h

I want to make sure we are respecting the recipient provider's response but it doesn't appear that postfix waited 180 seconds before reattempting delivery as I would have expected.

I have a server running Ubuntu 18.04 which has been experiencing huge CPU spike that nearly brings Apache to a halt once or twice a day. The server runs a couple of websites - all php & mysql driven applications. Here's a bit more detail on things I've looked into:

MySQL: Slow query log is enabled and set to log queries taking longer than 1 second. Reviewing this log after a spike reveals nothing in particular. No long running queries to speak of.

CRON: I've reviewed all user cron jobs running on the server and there's nothing that happens during the times when these spikes occur. There are only a couple of CPU intensive jobs and they run around 3am and take approx 5 minutes to complete.

PHP: Both max_input_time and max_execution_time are set to 60 seconds and memory_limit is 64M (this is a 16GB server which typically doesn't come close to maxing out memory usage).

APACHE: Our host (Linode) has a tool called Longview which shows various diagnostics related to Apache. Despite the huge spike in resources consumed, requests seem to be happening at a normal rate. Manually inspecting the access logs confirms this. Here's a screenshot of the Apache tab in Longview showing a spike in Workers, CPU and RAM this morning - as well as a relatively normal rate of Requests:

I've also added flags in the Apache access logs to show time and I/O data about each request. The end of the LogFormat is time:%T input:%I output:%O. None of the request or response sizes are unusually large (1MB might be the largest response I saw and that was for an image). The only thing standing out is the "time taken to serve the request" which is the %T flag. At a certain point in the morning many seemingly normal requests take 5 - 10 minutes to complete for no apparent reason.

I'm completely stumped at this point. Where can i go from here to diagnose the event that's triggering this?

Lately when I query whois from one of our servers I almost always receive the following message indicating that we are exceedind daily usage limits:

Queries from your IP address have passed the daily limit of controlled objects:

%ERROR:201: access denied for xxxx:xxxx:x:x:xxxx:xxxx:xxxx:xxxx
%
% Queries from your IP address have passed the daily limit of controlled objects.
% Access from your host has been temporarily denied.

This happens whether or not I've done any lookups at all on a given day. Since I have only occasionally used this tool in the past I am left wondering how the quota could have been used up since no one else has command line access to our server and I'm reasonably sure that there has been no security compromise.

My question: Are there linux services or daemons that make use of the RIPE database service?

In the default dovecot ssl config file the certificate file paths are specified like:

ssl_cert = </etc/dovecot/private/dovecot.pem

What is the purpose of that < symbol preceding the path?

UPDATE: A comment below contained a dead link to docs detailing this syntax. Here is the current working link which may be helpful to future readers: https://doc.dovecot.org/configuration_manual/config_file/#reading-value-from-file

Question: When specifying 2 or more address for the inet_interfaces directive, will postfix still bind outgoing mail to one of them?

The postfix docs state:

When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail.

Due to the need for a loopback address I need to be able to bind to either 127.0.0.1 or my WAN address depending on mail destination. My current setting is:

inet_interfaces = 23.45.67.89, [2600:1234::1234:5678:abcd:abcd], 127.0.0.1

Previously I had used smtp_bind_address and smtp_bind_address6 but was causing problems since postfix needs to access loopback for local mail delivery.

Also, I do in fact have 5 static IPv4 addresses for this server, hence the desire to only use one of them. Since the docs state just one IPv4 and/or IPv6 I'm unsure whether specifying all three will ensure that outgoing mail is bound to anything at all.

I have a mailserver forwarding mail and using postsrsd for SRS. Since postsrsd uses postfix's mydomain setting to alter the Return-Path, is there a way to set the SRS_DOMAIN for forwarded mail based on the recipient address instead of setting it statically? Since the mailserver handles mail for several different domains, I'd like the return path to match the recipient's domain, not the hostname of the mailserver.

I've set up Postfix, Dovecot and MySQL according to this tutorial from linode. In the virtual aliases table I have an account which forwards to my gmail.

Because these messages are then being delivered through my mailserver, which obviously is not designated as a permitted sender by the spf record of the originating domain, the messages are marked as "spf: fail" and have the added header like "[email protected] via myservername.com".

This makes perfect sense but I'm wondering if there is some way to deliver/forward these messages without the spf penalty? For now everything is fine as I have added filters in gmail such that forwarded mail will not be marked as, and delivered to spam. But historically, mail providers have a tendency to change and often tighten policies in regards to mail delivery, so for that reason I'd like to know if there is a better way to configure this.

I recently configured an (Ubuntu 14.04) server to use static IP addresses and noticed that: <Virtualhost *:80>

No longer seems to work. Previously the 000-default.conf file was used and by modifying it and adding each IP to the declaration it works again. But I'd rather be able to use a wildcard here and elsewhere if possible.

Most of the hosts I have configured are now explicitly stating which IP address(es) they correspond to, is there a way to configure apache so that the default (or any) virtual host configuration that will be used for any and all hostnames which don't have a match using a wildcard?

A webserver I manage is running Ubuntu 14.04 and is configured for dual stack - ipv6 & ipv4. It is my understanding that ipv6 connections have first priority after which it should fall back to ipv4.

Curiously, when inspecting the Apache server logs, I'm can see the two protocols being used alternately for connections from my office desktop which is ipv6 capable. One minute it uses ipv6, the next ipv4 with seemingly no rhyme or reason to why it chooses one or the other.

There are no apparent problems here - I'm just wondering what factors cause one protocol or the other to be used at different times when nothing has changed that I am aware of?

I currently manage two servers on Linode. The first "server-a" is running 12.04, the second "server-b" is a fresh install of 14.04.

A while ago I had some trouble with spf records on server-a and came to the realization that I needed to explicitly add (or create an A record for) the ipv6 address since the postfix service was using ipv6 to connect to gmail. This was surprising to me since I just assumed it would be using ipv4 by default. After a bit more followup I discovered that nearly all services were using ipv6 in some cases but not others.

For instance, if postfix delivers mail, or if I telnet or ssh to another host on Linode my ipv6 address shows up the log. On the other hand if I connect to my local server here at home or to one on Digital Ocean's network, ipv4 is used.

Can anyone explain when and how it is determined that ipv4 or ipv6 should be used when establishing a connection? Does it vary from service to service or is this part of a central configuration?

In the Cron manpage it mentions the special string "@reboot". Can I combine this with a regular schedule? The goal is simply to schedule a job to run once a day AND immediately in the event of a system reboot.