Perrschy's questions

For some reason, some extern websites have links to my website subdomain.example.com looking something like this: <a href="https://subdomain.example.com/https://subdomain.example.com/index.php?id=54597">Link</a>

I cannot get these links corrected as I have no control over these links. So instead of showing a 404 error, I would like to redirect https://subdomain.example.com/https://subdomain.example.com/index.php?id=54597 to https://subdomain.example.com/index.php?id=54597 via nginx but I cannot get a location to match, once it includes a colon. Is there a way to get this to work?

something like

location ~ "^https://subdomain.example.com/index.php$" {
  return 301 /index.php?$query_string;
}

I am trying to send an email to a recipient with an email address starting with a hyphen/dash, e.g. [email protected]

The recipient claims the mail address is correct.

mail.log shows:

postfix/smtpd[26055]: warning: Illegal address syntax from ...[...] in RCPT command: <[email protected]>

I am using Postfix 2.11.3

Any idea how I can send emails to such an address?

We send out newsletters / bulk mail (double opt-in of course). We automatically delete hard bounces (mailbox unavailable, user unknown, host unknown...) right away from our mailing lists.

But a lot of "Undelivered" mails are generated because the user's mailbox is full / the user is over quota. So the email address still exists, but the mailbox is full.

So the two most common scenarios are probably

a) the user is still using his account and will delete some emails in the near future so he's not over quota any more and can receive emails again.

b) the user abandoned his account (for whatever reason), it ran full and that's that. It will never be used again...

So the first scenario tells me to NOT delete the email address from our mailing list, the second scenario tells me I should delete it. Of course, I don't know.

What's the best strategy in terms of working on the "reputation of my mail server / IP address"? Should I try to send for the next few days / couple of weeks and if it's still not working, should I treat it as b)?

I would assume that most ESP would delete inactive / full email addresses after a certain time so they will become hard bounces anyways? Or would an ESP discourage sending mails to a full mailbox too often?

Our current setup is a webserver at www.domain.tld (DNS A record) and a mail server (postfix) at mail.domain.tld (DNS MX record) on one dedicated server (IP address 1.2.3.4).

Our website sends out newsletters every day to our subscribers so the current machine has to handle both, the webserver and mail server load.

We would like to "outsource" the newsletter delivery to a second dedicated mail server with IP address 4.3.2.1 at mail2.domain.tld.

So in addition to the current MX record mail to 1.2.3.4, we are planning to add a second MX record mail2 to 4.3.2.1 with lower priority.

Now we would like to continue to use our current mail server mail as before for our regular mail accounts (postfix, courier, DKIM, DMARC, SPF, virtual users is already set up). Further, our newsletter application hosted on the webserver at 1.2.3.4 should be using the new mail server at mail2 to send out newsletters, and relaying mails to @domain.tld sent to mail2 to mail. (It could be that some mails get sent to mail2.)

To my understanding, mail2.example.com should ONLY be allowed to send out mails when they come from 1.2.3.4, AND it should relay incoming mails to mail ONLY when they go to @domain.tld.

mail should continue to work for our "regular" mail accounts.

Thus, the "hard work" of sending out several thousand mails per day would be offloaded to the machine at 4.3.2.1 separating web and "newsletter" traffic.

How can I achieve this? We use Debian Jessie and postfix on both machines. I understand I can relay the incoming mail as similarly described here: Postfix : Relaying all incoming mail to another host

How do I get the "send newsletter" part?

If you need more specific information please let me know!

We recently switched to apache 2.4.18 on our production server and went all https/ssl (HTTP/2 with http2_module) with our website with about 100.000 visits per day.

We're using the worker MPM and PHP 5.6 via PHP-FPM (proxy_fcgi) since event MPM seems not yet to be working properly when using https.

Settings are:

<IfModule mpm_worker_module>
ServerLimit         16  
StartServers         8   
MinSpareThreads     64  
MaxSpareThreads      256 
ThreadLimit          64  
ThreadsPerChild      64  
MaxRequestWorkers     1024
MaxConnectionsPerChild   10000
</IfModule>

After the server is restarted, the number of threads on our Debian Jessie installation increases to several thousands after a few hours and apache error log fills up with these messages:

AH00288: scoreboard is full, not at MaxRequestWorkers

/server-status seems to indicate some weird "W sending reply" threads which don't do anything but have a very long running time:

W___KRK___KKC__C___KR__K__KKKRKKKKK___K__CC__KR____K__KK________
__KWR_KK_K_C__KC_KKKKKKK__KK__C_KKKKCK_KKK_C_K____WRKK_K_KKR_K_K
KK_CRKKKKRKKKKK__KK_WKCKK_KKKK_KWKKKWKKRRR__KK__K____KKKCK_KKKKK
_KK___K_W__K___CK_C___K____CRK____CKK_______KKKKKKCK___KCKK_KKK_
KK_KK_KK_KKKKK_K_KKK_KRKK_C_CKKR_C_KW__K_KWRK_KK_R_KR_K__KKK__K_
..............................C.........................W.......
...............................W..............................WW
............W.........W.........................................
.........W..........W....................W......................
.................W.......W......................................
.........................................................W......
CKKKKK_KK_KKKK_CKKKRK_RKRKKKKRRKKRKK_KC_KRKKK_KKKKKRKRRKKKKR_RK_
.............................................................W..
................................................................
................................................................
................................................................

All "W" threads look like this: Running for 1453710297 seconds which can't be true since the server was just restarted yesterday and nothing else.

5-0 21872   0/0/0   C   0.00    1453710297  0   0.0 0.00    0.00
5-0 21872   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
6-1 17300   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
6-1 17300   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
6-1 17300   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
7-1 4298    0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
7-1 4298    0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
8-1 4539    0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
8-1 4539    0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
8-1 4539    0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
9-1 21393   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
9-1 21393   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00
10-1    25117   0/0/0   W   0.00    1453710297  0   0.0 0.00    0.00

No indication what the request was in the last column.

loaded modules are:

apache2ctl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_groupfile_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 evasive20_module (shared)
 expires_module (shared)
 filter_module (shared)
 headers_module (shared)
 http2_module (shared)
 mime_module (shared)
 mpm_worker_module (shared)
 negotiation_module (shared)
 pagespeed_module (shared)
 proxy_module (shared)
 proxy_fcgi_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)

I've searched the web for days now and can't seem to find any solution. Help is greatly appreciated. If you need more info, details, logs, please let me know and point me to it.