Quantcast
Viewing all articles
Browse latest Browse all 14126

Emails from "mynetworks"

==== Required information ====
- iRedMail version (check /etc/iredmail-release):
- Linux/BSD distribution name and version:
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):
- Web server (Apache or Nginx):
- Manage mail accounts with iRedAdmin-Pro?
- Related log if you're reporting an issue:
======== Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.2
- Linux/BSD distribution name and version:
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx):
- Manage mail accounts with iRedAdmin-Pro? yes
- Related log if you're reporting an issue:
====

After migration to iRedMail emails from our webservers / monitoring scripts are rejected by iRedMail:

Recipient address rejected: Policy rejection

1.) NOQUEUE: reject: RCPT from unknown[xx.xx.xx.xx]: 554 5.7.1 <szsupport@example.com>: Recipient address rejected: Policy rejection; from=<> to=<szsupport@example.com> proto=ESMTP helo=<production.example.com>

- Recipient address exists and works
- maybe from=<> makes problem?

Anyway, I trust my servers and they should be allowed to send emails  to us despite some wrong settings.


Sender address rejected: Domain not found

2:) NOQUEUE: reject: RCPT from unknown[xx.xx.xx.xx]: 450 4.1.8 <root@postfix-fake-domain.com>: Sender address rejected: Domain not found;

- yes, the domain postfix-fake-domain.com doesn't exists but I don't care if our trusted server sends this rubbish.



Solution

- I did list our IP subnets in the mynetworks parameter at /etc/postfix/main.cf:

mynetworks = 127.0.0.1, [IP], [IP/Subnet], etc.


- I changed these rules:

smtpd_sender_restrictions =
        permit_mynetworks,
        reject_unknown_sender_domain,
        reject_non_fqdn_sender,
        reject_unlisted_sender,
        permit_sasl_authenticated

smtpd_recipient_restrictions =
        reject_unknown_recipient_domain,
        reject_non_fqdn_recipient,
        reject_unlisted_recipient,
        permit_mynetworks, <----- was listed after :7777
        check_policy_service inet:127.0.0.1:7777,
        permit_sasl_authenticated,
        reject_unauth_destination

Question

- is this solution acceptable or does it open the door for others (spamers)?
- is there better solution?


Viewing all articles
Browse latest Browse all 14126

Trending Articles