Docker-mailserver: Sending SPAM
Greetings
First of all, thanks for the great job you've been putting in this project !
The issue
My server is sending out SPAM. Or at least tries to. I don't really get how this is possible.
It seems to allow to send emails from "localhost" but how does emails even ended up coming from localhost, no clue there.
By the way, would it be better to update:
smtpd_recipient_restrictions =
reject_rbl_client zen.spamhaus.org, # this is already there
reject_rhsbl_reverse_client dbl.spamhaus.org, # to add ?
reject_rhsbl_helo dbl.spamhaus.org, # to add ?
reject_rhsbl_sender dbl.spamhaus.org # to add ?
Log of a SPAM trying to go out
Jun 8 06:28:46 post postfix/smtpd[1933]: 49ED9862737: client=localhost[127.0.0.1]
Jun 8 06:28:46 post postfix/cleanup[1973]: 49ED9862737: message-id=<pth7j94exf2pe0v11h3jj58t.1939171108191@MY_DOMAIN.COM>
Jun 8 06:28:46 post postfix/qmgr[1261]: 49ED9862737: from=<kmyu@MY_DOMAIN.COM>, size=1916, nrcpt=7 (queue active)
Jun 8 06:28:46 post amavis[1962]: (01962-12) Passed CLEAN {RelayedOpenRelay}, [61.91.169.238]:55145 [61.91.169.238] <kmyu@MY_DOMAIN.COM> -> <[email protected]>,<[email protected]>,<[email protected]>,<[email protected]>,<[email protected]>,<[email protected]>,<[email protected]
[email protected]
[email protected]>, Queue-ID: 6428786272C, Message-ID: <pth7j94exf2pe0v11h3jj58t.1939171108191@MY_DOMAIN.COM>, mail_id: klc4vFn2xxxH, Hits: -1.098, size: 1572, queued_as: 49ED9862737, dkim_sd=mail:swanest.com, 992 ms
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:46 post postfix/smtp[2017]: 6428786272C: to=<[email protected]
[email protected]
[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=67, delays=66/0/0/0.99, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 49ED9862737)
Jun 8 06:28:47 post postfix/smtp[2033]: 49ED9862737: host mx.spamexperts.com[31.204.154.237] said: 451-91.134.254.3 is not yet authorized to deliver mail from <kmyu@MY_DOMAIN.COM> 451 to <[email protected]
[email protected]
[email protected]>. Please try later. (in reply to RCPT TO command)
Jun 8 06:28:47 post postfix/smtp[2055]: 49ED9862737: to=<[email protected]>, relay=spamfilter.lhric.org[166.109.20.141]:25, delay=1, delays=0/0/0.69/0.32, dsn=2.0.0, status=sent (250 2.0.0 Message received OK [[email protected]])
Jun 8 06:28:48 post postfix/smtp[2037]: 49ED9862737: to=<[email protected]>, relay=hawaiianelectric-com.mail.protection.outlook.com[216.32.180.42]:25, delay=2.6, delays=0/0/1.3/1.4, dsn=2.6.0, status=sent (250 2.6.0 <pth7j94exf2pe0v11h3jj58t.1939171108191@MY_DOMAIN.COM> [InternalId=4037269261920, Hostname=MWHPR03MB2701.namprd03.prod.outlook.com] 10080 bytes in 0.194, 50.676 KB/sec Queued mail for delivery)
Jun 8 06:28:49 post postfix/smtp[2043]: 49ED9862737: to=<[email protected]>, relay=southplainscollege-edu.mail.protection.outlook.com[207.46.163.42]:25, delay=3.6, delays=0/0/2.2/1.4, dsn=2.6.0, status=sent (250 2.6.0 <pth7j94exf2pe0v11h3jj58t.1939171108191@MY_DOMAIN.COM> [InternalId=71051643978381, Hostname=DM3PR1101MB1181.namprd11.prod.outlook.com] 10029 bytes in 0.186, 52.623 KB/sec Queued mail for delivery)
Jun 8 06:28:50 post postfix/smtp[2036]: 49ED9862737: to=<[email protected]>, relay=locke.lewiscenter.org[163.150.129.103]:25, delay=3.8, delays=0/0/2.5/1.3, dsn=2.0.0, status=sent (250 Ok: queued as A92CD362842)
Jun 8 06:29:00 post postfix/smtp[2035]: 49ED9862737: to=<[email protected]>, relay=mail.bookrescue.com[66.147.242.173]:25, delay=14, delays=0/0/8.7/5.2, dsn=5.0.0, status=bounced (host mail.bookrescue.com[66.147.242.173] said: 550 No Such User Here (in reply to RCPT TO command))
Jun 8 06:29:04 post postfix/smtp[2033]: 49ED9862737: to=<[email protected]
[email protected]
[email protected]>, relay=mx.spamexperts.com[198.7.58.151]:25, delay=18, delays=0/0/2.7/16, dsn=4.0.0, status=deferred (host mx.spamexperts.com[198.7.58.151] said: 451-91.134.254.3 is not yet authorized to deliver mail from <kmyu@MY_DOMAIN.COM> 451 to <[email protected]
[email protected]
[email protected]>. Please try later. (in reply to RCPT TO command))
Jun 8 06:29:28 post postfix/smtp[2025]: 49ED9862737: to=<[email protected]>, relay=gpepublishing.com[72.52.226.16]:25, delay=43, delays=0/0/22/21, dsn=2.0.0, status=sent (250 OK id=1dIqwc-000Jod-Kv)
Jun 8 06:29:28 post postfix/bounce[2060]: 49ED9862737: sender non-delivery notification: E33AF86273B
Jun 8 06:37:02 post postfix/smtp[1613]: 49ED9862737: host mx.spamexperts.com[69.64.57.52] said: 451-91.134.254.3 is not yet authorized to deliver mail from <kmyu@MY_DOMAIN.COM> 451 to <[email protected]
[email protected]
[email protected]>. Please try later. (in reply to RCPT TO command)
Jun 8 06:37:04 post postfix/smtp[1613]: 49ED9862737: to=<[email protected]
[email protected]
[email protected]>, relay=mx.spamexperts.com[198.7.58.151]:25, delay=498, delays=483/0.07/14/1.1, dsn=4.0.0, status=deferred (host mx.spamexperts.com[198.7.58.151] said: 451-91.134.254.3 is not yet authorized to deliver mail from <kmyu@MY_DOMAIN.COM> 451 to <[email protected]
[email protected]
[email protected]>. Please try later. (in reply to RCPT TO command))
I just removed email addresses to protect privacy. The email seems to come from "kmyu@MY_DOMAIN.COM" which does not even exists...
YouriT
All 37 comments
What about adding this by default to postfix/main.cf:
unverified_sender_reject_reason = Address verification failed
address_verify_map = texthash:/etc/postfix/vmailbox
I think it would make already make sense not send emails "from" unknown address no?
I've the impression I'm acting as an OpenRelay because postfix smtpd always reports:
```
postfix/smtpd[1647]: connect from localhost[127.0.0.1]
````
YouriT
on 8 Jun 2017
I got it working way better now. I override this config of postfix and no SPAMs anymore:
unverified_sender_reject_reason = Address verification failed
address_verify_map = texthash:/etc/postfix/vmailbox
smtpd_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_unauth_pipelining,permit_dnswl_client list.dnswl.org,reject_rbl_client b.barracudacentral.org,reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
smtpd_sender_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unknown_sender_domain,reject_unknown_address,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_rhsbl_reverse_client dbl.spamhaus.org,reject_rbl_client b.barracudacentral.org
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,check_policy_service unix:private/policyd-spf,check_policy_service inet:127.0.0.1:10023,reject_unauth_pipelining,reject_invalid_helo_hostname,reject_non_fqdn_helo_hostname,reject_unknown_recipient_domain,permit_dnswl_client list.dnswl.org,reject_rhsbl_reverse_client dbl.spamhaus.org,reject_rhsbl_sender dbl.spamhaus.org,reject_rhsbl_client dbl.spamhaus.org,reject_rhsbl_sender fresh15.spameatingmonkey.net,reject_rhsbl_client fresh15.spameatingmonkey.net,reject_rhsbl_sender uribl.spameatingmonkey.net,reject_rhsbl_client uribl.spameatingmonkey.net,reject_rhsbl_sender urired.spameatingmonkey.net,reject_rhsbl_client urired.spameatingmonkey.net,reject_rhsbl_client hostkarma.junkemailfilter.com=127.0.0.2,reject_rbl_client b.barracudacentral.org,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spameatingmonkey.net,reject_rbl_client bl.spamcop.net,reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,reject_rbl_client dnsbl.njabl.org,reject_rbl_client bl.tiopan.com,reject_rbl_client spamsources.fabel.dk,reject_rbl_client truncate.gbudb.net,reject_rbl_client ubl.unsubscore.com,reject_rbl_client aspews.ext.sorbs.net,reject_rbl_client dnsbl.sorbs.net,reject_rbl_client backscatter.spameatingmonkey.net,reject_rbl_client bl.spameatingmonkey.net,permit
If you have any thoughts to share on the configuration it's more than welcome :)
YouriT
on 8 Jun 2017
Could you create a PR?
johansmitsnl
on 8 Sep 2017
Had too many issues, I'm not sure those parameters are optimal at all so I don't think it worth creating a PR with theses changes. But something certainly needs to be done.
YouriT
on 11 Sep 2017
A good think to do when you think you're acting as an open relay is to use this tool
tomav
on 11 Sep 2017
Did try that out but I couldn't get the perfect configuration. Everything was default so I guess there is something in the default config that isn't going right don't you think so?
YouriT
on 11 Sep 2017
I am having the same problem as @YouriT, it seems that my mail server is acting as an open relay.
Something definitely has to be done.
@YouriT can you tell me if the restriction using /etc/postfix/vmailbox worked as intended?
Steiniche
on 14 Sep 2017
I've been testing this as well... YouriT's solution does work but gives an error in greylisting. (port 10023)
Further it seems to do what it's supposed to :)
techgourmet
on 2 Oct 2017
I have been testing as well but I am not as succesful as you @techgourmet.
It seems that when the AV in the container hands over the request it is seen as an internal IP and is therefore always permitted due to permit_mynetworks.
Steiniche
on 2 Oct 2017
There was an omission in my success story
non-functioning greylisting rendered the solution worthless...and resulted in not being able to receive mail at all.
techgourmet
on 2 Oct 2017
Final working solution:
In main.cf:
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unknown_sender_domain,
reject_unknown_address,reject_rhsbl_sender dsn.rfc-ignorantt.org,
reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rbl_client b.barracudacentral.org,
check_sender_access hash:/etc/postfix/my-domains
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
rejecct_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_unauthh_pipelining,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_recipient_domain,
permit_dnswl_client list.dnswl.org,
reject_rhsbl_reverse_cclient dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_client dbl.spamhaus.org,
reject_rhsbl_sender fresh15.spameatingmonkey.net,
reject_rhsbl_cclient fresh15.spameatingmonkey.net,
reject_rhsbl_sender uribl.spameatingmonkey.neet,
reject_rhsbl_client uribl.spameatingmonkey.net,
reject_rhsbl_sender urired.spammeatingmonkey.net,
reject_rhsbl_client urired.spameatingmonkey.net,
reject_rhsbl_client hostkarma.junkemailfilter.com=127.0.0.2,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spameatingmonkey.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client bl.tiopan.com,
reject_rbl_client spamsources.fabel.dk,
reject_rbl_client truncate.gbudb.net,
reject_rbl_client ubl.unsubscore.com,
reject_rbl_client aspews.ext.sorbs.net,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client backscatter.spameatingmonkey.net,
reject_rbl_client bl.spameatingmonkey.net,
permit
To tie it together:
Create a file /etc/postfix/my-domains
Put the following text in the file:
maildomain.com REJECT (replace maildomain.com by your domain)
Execute the command postmap /etc/postfix/my-domains to create the hash
Reload postfix
- Hope this helps -
techgourmet
on 2 Oct 2017
Hallo, it seems that last night i started sending tons of spam, i've received ~3000 bounce email.
this is an example of mail sent
root@mail:/var/log/mail# grep -E "(C8D727ED3|022AEB6EEF)" mail.log.1
Nov 22 22:26:48 mail postfix/qmgr[949]: C8D727ED3: from=<[email protected]>, size=592, nrcpt=1 (queue active)
Nov 23 03:59:05 mail postfix/smtpd[1352]: 022AEB6EEF: client=localhost[127.0.0.1]
Nov 23 03:59:05 mail postfix/cleanup[16629]: 022AEB6EEF: message-id=<[email protected]>
Nov 23 03:59:05 mail amavis[17202]: (17202-01-56) Passed CLEAN {RelayedOpenRelay}, [not.my.own.ip]:3398 [not.my.own.ip] <[email protected]> -> <[email protected]>, Queue-ID: C8D727ED3, Message-ID: <[email protected]>, mail_id: k4cayCDxIZuT, Hits: -0.102, size: 906, queued_as: 022AEB6EEF, dkim_sd=mail:mydomain.tld, 1386 ms
Nov 23 03:59:05 mail postfix/smtp[17851]: C8D727ED3: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=56, delay=27978, delays=8042/19935/0/1.4, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 022AEB6EEF)
Nov 23 03:59:05 mail postfix/qmgr[949]: C8D727ED3: removed
Nov 23 07:04:38 mail postfix/qmgr[949]: 022AEB6EEF: from=<[email protected]>, size=1138, nrcpt=1 (queue active)
Nov 23 07:08:46 mail postfix/smtp[17575]: 022AEB6EEF: to=<[email protected]>, relay=hotmail-com.olc.protection.outlook.com[104.47.1.33]:25, delay=11382, delays=11135/247/0.29/0.3, dsn=2.6.0, status=sent (250 2.6.0 <[email protected]> [InternalId=70536247925952, Hostname=VE1EUR01HT140.eop-EUR01.prod.protection.outlook.com] 7183 bytes in 0.191, 36.703 KB/sec Queued mail for delivery)
Nov 23 07:08:46 mail postfix/qmgr[949]: 022AEB6EEF: removed
testing via telnet and nmap script it seems that is not possible to use my host as openrelay, but... it happened.
nmap --script /usr/share/nmap/scripts/smtp-open-relay.nse -p25,587 mydomain.tld
Starting Nmap 7.60 ( https://nmap.org ) at 2017-11-23 11:04 CET
Nmap scan report for mydomain.tld (m.y.i.p)
Host is up (0.0034s latency).
PORT STATE SERVICE
25/tcp open smtp
|_smtp-open-relay: Server doesn't seem to be an open relay, all tests failed
587/tcp open submission
|_smtp-open-relay: Server isn't an open relay, authentication needed
Nmap done: 1 IP address (1 host up) scanned in 23.56 seconds
This is the command:
docker run -d --rm \
--hostname mail.myhostname.tld \
--name mail \
-p "25:25" \
-p "143:143" \
-p "587:587" \
-p "993:993" \
-v /srv/mail/maildata:/var/mail \
-v /srv/mail/mailstate:/var/mail-state \
-v /srv/mail/config/:/tmp/docker-mailserver/ \
-v /etc/letsencrypt:/etc/letsencrypt \
-e SSL_TYPE=letsencrypt \
-e ENABLE_SPAMASSASSIN=1 \
-e ENABLE_CLAMAV=1 \
-e ENABLE_POSTGREY=1 \
-e ENABLE_FAIL2BAN=1 \
-e ONE_DIR=1 \
-e DMS_DEBUG=0 \
--cap-add NET_ADMIN \
--cap-add SYS_PTRACE \
tvial/docker-mailserver:latest ;
AlessandroLorenzi
on 23 Nov 2017
I have the same issue, tried the solution of @techgourmet and @YouriT, but still sending spam...
Feb 28 16:28:43 mail postfix/qmgr[4993]: 764B123659A: from=<srs0=t3f4=fv=usa.org=info@MY_DOMAIN.com>, size=1546, nrcpt=20 (queue active)
Feb 28 16:28:43 mail postfix/smtp[8415]: D684822608D: host mta7.am0.yahoodns.net[66.218.85.139] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command)
Feb 28 16:28:43 mail postfix/smtp[8415]: D684822608D: lost connection with mta7.am0.yahoodns.net[66.218.85.139] while sending RCPT TO
Feb 28 16:28:43 mail postfix/smtp[5038]: 03AA122EB34: to=<[email protected]>, relay=mta6.am0.yahoodns.net[98.137.159.26]:25, delay=106485, delays=105847/635/2.3/0.13, dsn=4.7.0, status=deferred (host mta6.am0.yahoodns.net[98.137.159.26] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command))
Feb 28 16:28:43 mail postfix/smtp[5208]: CC9DB228918: host mx-aol.mail.gm0.yahoodns.net[98.136.101.116] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command)
Feb 28 16:28:43 mail postfix/smtp[5208]: CC9DB228918: lost connection with mx-aol.mail.gm0.yahoodns.net[98.136.101.116] while sending RCPT TO
Feb 28 16:28:43 mail postfix/error[8465]: 712FE228465: to=<[email protected]>, relay=none, delay=110270, delays=110269/0/0/0.84, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mx2.dellcorporate.iphmx.com[2620:101:2001:d100::20]:25: Cannot assign requested address)
Feb 28 16:28:43 mail postfix/smtp[7007]: A36982320F9: host mx-aol.mail.gm0.yahoodns.net[66.218.85.151] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command)
Feb 28 16:28:43 mail postfix/smtp[7007]: A36982320F9: lost connection with mx-aol.mail.gm0.yahoodns.net[66.218.85.151] while sending RCPT TO
Feb 28 16:28:43 mail postfix/smtp[8622]: CC9DB228918: host mta7.am0.yahoodns.net[98.136.101.117] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command)
Feb 28 16:28:43 mail postfix/smtp[8622]: CC9DB228918: lost connection with mta7.am0.yahoodns.net[98.136.101.117] while sending RCPT TO
Feb 28 16:28:43 mail postfix/smtp[5065]: Trusted TLS connection established to mx-aol.mail.gm0.yahoodns.net[66.218.85.151]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Feb 28 16:28:43 mail postfix/smtp[5364]: A36982320F9: host mta7.am0.yahoodns.net[74.6.137.64] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command)
Feb 28 16:28:43 mail postfix/smtp[5364]: A36982320F9: lost connection with mta7.am0.yahoodns.net[74.6.137.64] while sending RCPT TO
Feb 28 16:28:43 mail postfix/smtp[5067]: Trusted TLS connection established to mta6.am0.yahoodns.net[74.6.137.64]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Feb 28 16:28:43 mail postfix/smtp[8414]: 6782922D7A7: to=<[email protected]>, relay=mta5.am0.yahoodns.net[98.137.159.24]:25, delay=94265, delays=93627/635/2.2/0.12, dsn=4.7.0, status=deferred (host mta5.am0.yahoodns.net[98.137.159.24] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command))
Feb 28 16:28:43 mail postfix/smtp[8414]: 6782922D7A7: to=<[email protected]>, relay=mta5.am0.yahoodns.net[98.137.159.24]:25, delay=94265, delays=93627/635/2.2/0.12, dsn=4.7.0, status=deferred (host mta5.am0.yahoodns.net[98.137.159.24] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command))
Feb 28 16:28:43 mail postfix/smtp[8414]: 6782922D7A7: to=<[email protected]>, relay=mta5.am0.yahoodns.net[98.137.159.24]:25, delay=94265, delays=93627/635/2.2/0.12, dsn=4.7.0, status=deferred (host mta5.am0.yahoodns.net[98.137.159.24] said: 421 4.7.0 [TSS04] Messages from 173.249.37.4 temporarily deferred due to user complaints - 4.16.55.1; see https://help.yahoo.com/kb/postmaster/SLN3434.html (in reply to MAIL FROM command))
Feb 28 16:28:43 mail postfix/qmgr[4993]: 78D78221EC6: from=<srs0=2pv+=fu=lee.com=info@MY_DOMAIN.com>, size=2258, nrcpt=50 (queue active)
Feb 28 16:28:43 mail postfix/error[8260]: 5F6ED237B7C: to=<[email protected]>, relay=none, delay=56571, delays=55933/638/0/0.01, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to home.com[184.168.221.104]:25: Connection refused)
I used the following yaml:
version: '2'
services:
mail:
image: tvial/docker-mailserver:latest
hostname: mail
domainname: MY_DOMAIN.com
container_name: mail
restart: always
ports:
- "25:25"
- "143:143"
- "587:587"
- "993:993"
volumes:
- mailstate:/var/mail-state
- /configs/mail/:/tmp/docker-mailserver/
- /volumes/letsencrypt/mail.pingbo.de/:/etc/letsencrypt/live/mail.MY_DOMAIN.com/
- /volumes/mail_data:/var/mail
environment:
- ENABLE_SPAMASSASSIN=1
- SA_TAG=undef
- SA_TAG2=6.31
- SA_KILL=20
- ENABLE_CLAMAV=1
- ENABLE_FAIL2BAN=1
- ENABLE_POSTGREY=1
- ONE_DIR=1
- DMS_DEBUG=0
- ENABLE_MANAGESIEVE=1
- SSL_TYPE=letsencrypt
- PERMIT_DOCKER=host
cap_add:
- NET_ADMIN
- SYS_PTRACE
Pingbo
on 28 Feb 2018
What version of the docker image are you running?
Current image is:
tvial/docker-mailserver latest c8ebefa3c259 21 hours ago 513MB
I ask this because I'm missing the new postfix/postscreen feature in the logs you send.
johansmitsnl
on 28 Feb 2018
I'm currently using this one:
tvial/docker-mailserver latest a2a38b6bd970 3 days ago 514MB
Pingbo
on 28 Feb 2018
After some chatting with @Pingbo it looks like a firewall issue. The source IP of the client connecting to the docker is masqueraded and does not show the real IP. Because of the docker host permit the local ip's are permitted and therefore allows everyone to send. He is investigating.
@YouriT do you also run with iptables disabled for docker?
johansmitsnl
on 28 Feb 2018
@johansmitsnl nice that you guys are looking into this.
When you say firewall issue is it an external firewall, as in external to docker or something related to the container it self?
Steiniche
on 28 Feb 2018
@Steiniche
In my case i'm running docker behind an ufw firewall, so ufw is masquerading the traffic...
Thats the only problem with ufw and docker together. Because if you want ufw you need to disable iptables in docker...
Therfore i have to put in a direct nat that the container will get the "real" source IP again.
So thats a general issue with docker/ufw not with the image
Pingbo
on 28 Feb 2018
@Steiniche do you also have a similar setup?
Would be nice if it matches up so we got track of the problem and focus on how to solve.
johansmitsnl
on 1 Mar 2018
Sorry but I won't be able to help I abandoned using this project.
YouriT
on 1 Mar 2018
Hi all, I had an issue with ufw and docker and came to the conclusion below. Please correct me if I'm wrong! :)
I guess ufw and docker aren't really compatible since it seems that ufw places its iptables rules after docker, hence the ufw rules are not evaluated for docker ports/services.
Disabling the default docker iptables rules and going for a custom "bridging/host network and iptables" approach (with security issues) is complicated.
A suggestion for best practice would be to avoid using ufw for everything docker related and instead go with the docker defaults. ufw could probably still be used on other ports/services though. If additional iptables rules are required they can always be added manually (and with greater precision at that!).
boaorm
on 1 Mar 2018
@johansmitsnl no my server does not run ufw so unfortunately this does not seem to be the pattern.
At least not for the issue I am experiencing.
I still believe the problem to be affect by AV and docker IPs.
It seems that when the AV in the container hands over the request it is seen as an internal IP and is therefore always permitted due to permit_mynetworks.
Steiniche
on 2 Mar 2018
@Steiniche AV as in Antivirus?
johansmitsnl
on 2 Mar 2018
@johansmitsnl yeah specifically ENABLE_CLAMAV=1
When CLAMAV looks at the mail and decides it can be passed it will be passed with an internal docker IP which makes postfix think that the sender is okay.
At least that is my current though process about it.
Steiniche
on 2 Mar 2018
@Steiniche Could you provide a log with and without clamav enabled?
Clamav does only scan the email and does not mangle the IP.
johansmitsnl
on 2 Mar 2018
Here is one mail which seems to go through with a standard docker-mailserver container.
It seems to be happening with and without clamav being enabled.
Mar 4 16:35:27 mail postfix/postscreen[895]: CONNECT from [172.21.0.1]:42624 to [172.21.0.2]:25
Mar 4 16:35:27 mail postfix/postscreen[895]: WHITELISTED [172.21.0.1]:42624
Mar 4 16:35:27 mail postfix/smtpd[896]: connect from unknown[172.21.0.1]
Mar 4 16:35:27 mail opendmarc[200]: ignoring connection from [172.21.0.1]
Mar 4 16:35:27 mail postfix/smtpd[896]: A23952D8A74: client=unknown[172.21.0.1]
Mar 4 16:35:28 mail postfix/cleanup[904]: A23952D8A74: message-id=<>
Mar 4 16:35:28 mail opendkim[194]: A23952D8A74: no signing table match for '[email protected]'
Mar 4 16:35:28 mail opendkim[194]: A23952D8A74: no signature data
Mar 4 16:35:28 mail postfix/qmgr[1058]: A23952D8A74: from=<[email protected]>, size=389, nrcpt=1 (queue active)
Mar 4 16:35:28 mail postfix/smtpd[896]: disconnect from unknown[172.21.0.1] ehlo=1 mail=1 rcpt=1 data=1 rset=1 quit=1 commands=6
Mar 4 16:35:29 mail postfix/smtpd[918]: connect from localhost[127.0.0.1]
Mar 4 16:35:29 mail postfix/smtpd[918]: 92A182D8A7D: client=localhost[127.0.0.1]
Mar 4 16:35:29 mail postfix/cleanup[904]: 92A182D8A7D: message-id=<[email protected]>
Mar 4 16:35:29 mail postfix/qmgr[1058]: 92A182D8A7D: from=<[email protected]>, size=652, nrcpt=1 (queue active)
Mar 4 16:35:29 mail amavis[5224]: (05224-01) Passed CLEAN {RelayedOutbound}, LOCAL [172.21.0.1]:42624 <[email protected]> -> <[email protected]>, Queue-ID: A23952D8A74, mail_id: 7IchC9ZEdT4G, Hits: 6.165, size: 352, queued_as: 92A182D8A7D, 1532 ms
Mar 4 16:35:29 mail postfix/smtp[909]: A23952D8A74: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.1, delays=0.53/0.04/0.01/1.5, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 92A182D8A7D)
Mar 4 16:35:29 mail postfix/qmgr[1058]: A23952D8A74: removed
@Steiniche thats what I thought, I run with clamav on and don't experience this.
My docker-compose file is, I use a specific network for my docker containers. You can ignore the ipv6 is not available but it is the bridge driver, you use this to?
mail:
image: tvial/docker-mailserver:latest
networks:
- app_net
networks:
app_net:
driver: bridge
enable_ipv6: true
ipam:
driver: default
config:
- subnet: 172.16.38.0/24
- subnet: fd00:aaaa:bbbb::/48
Yeah I use a specific network as I use docker-compose, it just creates a default bridge network to use.
Furthermore, I run with:
cap_add:
- NET_ADMIN
To allow FAIL2BAN to work, but it does not seem to do much though.
Steiniche
on 4 Mar 2018
but you have this problem with all server like applications?
Like apache/nginx etc..?
johansmitsnl
on 4 Mar 2018
@johansmitsnl I am unsure what you mean about "this problem" and "all server like applications"?
What I am experiencing is that this docker image seem to have some unsafe defaults which allows it to be used as an open relay in some cases.
Steiniche
on 5 Mar 2018
@Steiniche I think the "unsafe" defaults are related to the limitation of the docker setup you run that masks the original IP and communicates with the docker network IP that you allowed with PERMIT_DOCKER.
When you change the variable to "empty" is it still an open relay?
With "all server like applications" I mean when you have nginx running and you access it does a docker IP show or the real client ip?
I guess this is open relay issue is not related to the image itself but on the configuration.
When you run this docker: docker run --rm -p 3000:3000 panj/debugging-simple-server
and you access the server curl http://SERVER_IP:3000 what IP does appear?
In my setup it looks like this:
{
"method": "GET",
"url": "/",
"header": {
"host": "149.xxx.xxx.xxx:3000",
"user-agent": "curl/7.58.0",
"accept": "*/*"
},
"ip": "::ffff:83.xxx.xxx.xxx",
"ips": []
}
You can see the IP is my client IP, I guess when you test this it shows the docker internal gateway id on your setup.
johansmitsnl
on 5 Mar 2018
Thanks for clarifying.
When I run the debugging-simple-server I actually get a 172.xx.xx.xx/16 IP which is the docker internal network IP.
The same goes for the nginx container.
It does not seem to be related to the PERMIT_DOCKER=host configuration as this was not configured in the nginx and debugging-simple-server tests.
I think you are right that this can lead to the "unsafe" defaults in the configurations as they are not configured to support internal docker IPs.
Debug information:
Docker version 17.05.0-ce
There does currently not exist a newer version for the os I am running.
Steiniche
on 5 Mar 2018
@Steiniche thats what I thought. The PERMIT_DOCKER is a ENV variable that works only for the mailserver image.
The network driver you use is also bridge? Can you post the section of the network and image definition of your compose file? What OS are you running on?
I use Ubuntu 16.04 for my server.
johansmitsnl
on 5 Mar 2018
The network driver is bridge, it is create with everything default, therefore there is no network section in my compose file.
I am running on a synology.
The important parts of my compose file can be found below
services:
mail:
image: tvial/docker-mailserver:latest
hostname: mail
domainname: mydomain.com
container_name: mail
restart: unless-stopped
ports:
- "25:25"
- "143:143"
- "587:587"
- "993:993"
environment:
- ENABLE_SPAMASSASSIN=1
- ENABLE_CLAMAV=0
- ENABLE_FAIL2BAN=1
- ENABLE_POSTGREY=1
- ONE_DIR=1
- SSL_TYPE=manual
- SSL_CERT_PATH=/tmp/ssl/fullchain.pem
- SSL_KEY_PATH=/tmp/ssl/key.pem
- PERMIT_DOCKER=host #fix SPF fail by copying the IPv4 of the docker container into the postfix cfg
- DMS_DEBUG=0
cap_add:
- NET_ADMIN #this is needed for FAIL2BAN to do its magic
Looks like a synology issue. Don't know this platform well, are there simular issues on the internet for this device?
johansmitsnl
on 5 Mar 2018
It seems to be more of a moby problem: https://github.com/moby/moby/issues/15086
Steiniche
on 5 Mar 2018
Seems this is more a networking/docker/config issue than an issue with docker-mailserver itself and there has been no activity since early 2018. I'll close this, please reopen or post a new issue based on the current image if the problem persists.
erik-wramner
on 14 Aug 2019
Related issues
Mathieu-R
路
4Comments
H4R0
路
3Comments
ShuP1
路
4Comments
Hamsterman
路
3Comments
capi
路
4Comments
Most helpful comment
I got it working way better now. I override this config of postfix and no SPAMs anymore:
If you have any thoughts to share on the configuration it's more than welcome :)