Mailu - Revision history

Leo at 23:38, 14 June 2020

2020-06-14T23:38:17Z

← Older revision		Revision as of 23:38, 14 June 2020
Line 62:		Line 62:

	The 'fix' is to just raise the limits. This however defeats the whole point of a rate limit (ie. to prevent brute force attacks).		The 'fix' is to just raise the limits. This however defeats the whole point of a rate limit (ie. to prevent brute force attacks).

			{{Navbox Linux}}[[Category:Linux]]
			[[Category:LinuxUtilities]]
			[[Category:Containers]]

Leo: /* Amazon Web Services */

2020-01-28T23:13:31Z

Amazon Web Services

← Older revision		Revision as of 23:13, 28 January 2020
Line 35:		Line 35:
	first_header_checks:		first_header_checks:
	{{highlight\|lang=text\|code=		{{highlight\|lang=text\|code=
	~~/^Reply-To:(\s)?(.*)$/i REPLACE X-Original-Reply-To: $2~~
	/^To:(\s)?(.*)$/i PREPEND X-Original-To: $2		/^To:(\s)?(.*)$/i PREPEND X-Original-To: $2
	/^From:(\s)?(.*)/i PREPEND X-Original-From: $2		/^From:(\s)?(.*)/i PREPEND X-Original-From: $2

Leo: /* Amazon Web Services */

2020-01-28T22:51:48Z

Amazon Web Services

← Older revision		Revision as of 22:51, 28 January 2020
Line 18:		Line 18:
	=== Amazon Web Services ===		=== Amazon Web Services ===
	Running mailu on a EC2 instance is identical. However, there are some caveats:		Running mailu on a EC2 instance is identical. However, there are some caveats:
			* AWS limits SMTP traffic unless you ask for an exception
	* IPs assigned from AWS's ElasticIP pool have a low reputation. Some are even blacklisted by SpamHaus		* IPs assigned from AWS's ElasticIP pool have a low reputation. Some are even blacklisted by SpamHaus
	* AWS limits SMTP traffic unless you ask for an exception		* Using AWS SES as a mail relay works except for forwarded messages because of unverified address set in the 'From' header.
	* Using AWS SES as a mail relay works except for forwarded messages because of unverified address set in the '~~envelope from~~' header.

	You can try obtaining various Elastic IP addresses until you get one that is clean. However, mail sent is ~~really~~ unreliable since gmail sometimes just refuses the email from being accepted ~~completely~~.		Some IPs are worse than others. You can try obtaining various Elastic IP addresses until you get one that is clean. However, mail sent is still unreliable since gmail sometimes just refuses the email from being accepted.

	~~Using~~ SES as a mail relay gets around the unreliable delivery issue, ~~but~~ emails that are forwarded won't be delivered since the sender isn't recognized by SES. You can get around this by rewriting the envelope sender to a verified address ~~while ensuring~~ the reply-to header ~~is rewritten~~ with the original sender address ~~by editing postfix:~~		Instead of sending mail from your EC2 instance directly, you could try using SES as a mail relay. This gets around the unreliable delivery issue. However, emails that are forwarded won't be delivered since the sender isn't recognized by SES. You can get around this by rewriting the envelope sender to a verified address. Even better is if you can also rewrite the reply-to header with either the original reply-to address or the original sender address.

	main.cf:		main.cf:

Leo: /* Amazon Web Services */

2020-01-28T22:46:42Z

Amazon Web Services

@@ Line 24: / Line 24: @@
 You can try obtaining various Elastic IP addresses until you get one that is clean. However, mail sent is really unreliable since gmail sometimes just refuses the email from being accepted completely.
-Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES. You could possibly get around this by changing the sender address to a verified address and then have the reply-to header set to the original sender address...
+Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES. You can get around this by rewriting the envelope sender to a verified address while ensuring the reply-to header is rewritten with the original sender address by editing postfix:
-See:
+main.cf:
 * https://serverfault.com/questions/681278/forwarding-email-with-postfix-via-aws-ses
 * https://forums.aws.amazon.com/thread.jspa?threadID=75133
+* https://serverfault.com/questions/833906/rewrite-from-for-specific-to-addresses
 == Troubleshooting ==

Leo at 19:11, 28 January 2020

2020-01-28T19:11:19Z

← Older revision		Revision as of 19:11, 28 January 2020
Line 20:		Line 20:
	* IPs assigned from AWS's ElasticIP pool have a low reputation. Some are even blacklisted by SpamHaus		* IPs assigned from AWS's ElasticIP pool have a low reputation. Some are even blacklisted by SpamHaus
	* AWS limits SMTP traffic unless you ask for an exception		* AWS limits SMTP traffic unless you ask for an exception
	* Using AWS SES as a mail relay works except for forwarded messages		* Using AWS SES as a mail relay works except for forwarded messages because of unverified address set in the 'envelope from' header.

	You can try obtaining various Elastic IP addresses until you get one that is clean. However, mail sent is really unreliable since gmail sometimes just refuses the email from being accepted completely.		You can try obtaining various Elastic IP addresses until you get one that is clean. However, mail sent is really unreliable since gmail sometimes just refuses the email from being accepted completely.

	Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES.		Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES. You could possibly get around this by changing the sender address to a verified address and then have the reply-to header set to the original sender address...

	See:		See:
	* https://serverfault.com/questions/681278/forwarding-email-with-postfix-via-aws-ses		* https://serverfault.com/questions/681278/forwarding-email-with-postfix-via-aws-ses
			* https://forums.aws.amazon.com/thread.jspa?threadID=75133


	== Troubleshooting ==		== Troubleshooting ==

Leo: /* Amazon Web Services */

2020-01-27T18:29:05Z

Amazon Web Services

← Older revision		Revision as of 18:29, 27 January 2020
Line 25:		Line 25:

	Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES.		Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES.

			See:
			* https://serverfault.com/questions/681278/forwarding-email-with-postfix-via-aws-ses

	== Troubleshooting ==		== Troubleshooting ==

Leo at 18:28, 27 January 2020

2020-01-27T18:28:40Z

← Older revision		Revision as of 18:28, 27 January 2020
Line 15:		Line 15:

	Once the containers have started, you should be able to navigate to the admin console under {{code\|/admin}}.		Once the containers have started, you should be able to navigate to the admin console under {{code\|/admin}}.

			=== Amazon Web Services ===
			Running mailu on a EC2 instance is identical. However, there are some caveats:
			* IPs assigned from AWS's ElasticIP pool have a low reputation. Some are even blacklisted by SpamHaus
			* AWS limits SMTP traffic unless you ask for an exception
			* Using AWS SES as a mail relay works except for forwarded messages

			You can try obtaining various Elastic IP addresses until you get one that is clean. However, mail sent is really unreliable since gmail sometimes just refuses the email from being accepted completely.

			Using SES as a mail relay gets around the unreliable delivery issue, but emails that are forwarded won't be delivered since the sender isn't recognized by SES.

	== Troubleshooting ==		== Troubleshooting ==

Leo: /* Periodic 'Authentication Failed' Errors */

2019-11-24T22:55:50Z

Periodic 'Authentication Failed' Errors

← Older revision		Revision as of 22:55, 24 November 2019
Line 20:		Line 20:
	Looking at the logs, you see:		Looking at the logs, you see:
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
	front_1 {{!}}\| 2019/11/24 22:34:26 [info] 10#10: *216931 client login failed: "Authentication rate limit from one source exceeded" while in http auth state, client: 192.168.203.8, server: 0.0.0.0:10143, login: "user@domain.com"		front_1 {{!}} 2019/11/24 22:34:26 [info] 10#10: *216931 client login failed: "Authentication rate limit from one source exceeded" while in http auth state, client: 192.168.203.8, server: 0.0.0.0:10143, login: "user@domain.com"
	}}		}}

Leo: /* Troubleshooting */

2019-11-24T22:55:07Z

Troubleshooting

← Older revision		Revision as of 22:55, 24 November 2019
Line 20:		Line 20:
	Looking at the logs, you see:		Looking at the logs, you see:
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
	front_1 \| 2019/11/24 22:34:26 [info] 10#10: *216931 client login failed: "Authentication rate limit from one source exceeded" while in http auth state, client: 192.168.203.8, server: 0.0.0.0:10143, login: "user@domain.com"		front_1 {{!}}\| 2019/11/24 22:34:26 [info] 10#10: *216931 client login failed: "Authentication rate limit from one source exceeded" while in http auth state, client: 192.168.203.8, server: 0.0.0.0:10143, login: "user@domain.com"
	}}		}}

	It looks like rainloop is causing a bunch of authentication requests for each HTTP request that is served. This then causes the authentication rate limit to hit.		It looks like rainloop is causing a bunch of authentication requests for each HTTP request that is served. This then causes the authentication rate limit to hit.

			The 'fix' is to just raise the limits. This however defeats the whole point of a rate limit (ie. to prevent brute force attacks).

Leo at 22:49, 24 November 2019

2019-11-24T22:49:34Z

← Older revision		Revision as of 22:49, 24 November 2019
Line 15:		Line 15:

	Once the containers have started, you should be able to navigate to the admin console under {{code\|/admin}}.		Once the containers have started, you should be able to navigate to the admin console under {{code\|/admin}}.

			== Troubleshooting ==
			=== Periodic 'Authentication Failed' Errors ===
			Looking at the logs, you see:
			{{highlight\|lang=terminal\|code=
			front_1 \| 2019/11/24 22:34:26 [info] 10#10: *216931 client login failed: "Authentication rate limit from one source exceeded" while in http auth state, client: 192.168.203.8, server: 0.0.0.0:10143, login: "user@domain.com"
			}}

			It looks like rainloop is causing a bunch of authentication requests for each HTTP request that is served. This then causes the authentication rate limit to hit.