Create a custom_replies map (i.e. /etc/postfix/custom_replies) with the following contents:
email@example.com REJECT Like I said, NOREPLY
Run sudo postmap /etc/postfix/custom_replies.
Edit /etc/postfix/main.cf and put the following as the first check of the smtpd_recipient_restrictions:
As long as you bounce the mail by refusing to receive it in the first place, then a spammer cannot use you to annoy somebody innocent with a lot of bounces.
You can either return an error on the RCPT TO command, which is what usually happens in case of a non-existent address, or you can return success on the RCPT TO command but return an error at the end of ...
They recommend to keep retrying and eventually the IP should get
greylisted. We've configured our Postfix to do this. All bounced
emails get retried a few times but Mimecast is not removing us off
If you will forgive me, I'm not sure you quite understand greylisting. As Mimecraft's docs say, the identifier for a greylisting decision ...
If it's being blocked due to an SPF record, then ideally they need to correct their SPF records to include their sending MX hosts.
The reason it will be blocked by your mail servers and not others is purely down the configuration of mail servers or relays in your organisation to honor SPF records of the sender. Other organisations chose not to honor SPF.
As have said mschuett, you can use regexp
First check that postfix supports regexp:
root @ mail / # postconf-m | grep regexp
root @ mail / #
Create the file /etc/postfix/aliases-regexp and add to it your regexp
root @ mail / # cat /etc/postfix/aliases-regexp
root @ mail / #
To receive emails from other servers, you need to be listening on port 25. Port 587 is the submission port, intended for clients to submit mail for delivery. Other mail servers will never try to connect to this port.
The mail server mx.maxus.pl attempted to look up the domain name in the From: email address, firstname.lastname@example.org, and was unable to find it.
This means your recipient's mail server is having trouble resolving domain names correctly, as I was able to look this up successfully.
The problem is with the recipient's mail system, not with your Google ...
Based on the information you've provided, this is almost certainly not coming from your server unless you run an open relay. The message originated in China:
inetnum: 18.104.22.168 - 22.214.171.124
descr: China Unicom Beijing province network
descr: China Unicom
As RFC3463 explains, status codes beginning with 5 are used for permanent failures and 4 for persistent transient failures. Instead of trying to parse several messages with different formats you could rely on server logs and try something like this:
grep " dsn=5." /var/log/mail.log | grep -o -P " to=<(.+?)>" | sort | uniq -c
This will find permanent ...
Generally there are two types of bounces
The bounces caused by directrejection of remote mail server when your postfix deliver the email.
The bounces caused by remote server (next-hop server after your postfix) fails to deliver the message to final recipients.
The first case was already covered by excellent answer by Esa Jokinen above. Your best bet is ...
What I usually do is set up a mail forwarder as a backup MX - that is, a mail server that isn't the destination for any emails but can hold on to them (leave them on hold) in case something goes wrong. The upside to this is that the moment your main mail server goes back up the emails start being delivered as if nothing happened - you don't have multiple ...
I'm going to make this answer fairly generic because the terminology and configuration details will vary depending on your specific mail server/spam filter software.
There are actually 3 approaches for an invalid recipient:
After the recipient is determined to be invalid, send an Undeliverable message back to the sender.
Close the SMTP connection while the ...
Accoding to the answers given at
The answer is 254 according to RFC 5321
So, those MTA are badly configured.
Cite from RFC 5321 126.96.36.199. Extended HELLO (EHLO) or HELLO (HELO)
The argument field contains the fully-qualified domain name of the SMTP client if one is available.
In other words it should be FQDN which resolves into IP address your sending from. So, if you are sending mail from IP 188.8.131.52 and mail.domain.com resolves into 184.108.40.206 (and 12.34.56....
Hand this responsibility over to somebody else. Postini, AppRiver, and Symantec are all examples of companies that do this for you. Let them filter your spam before it gets to your network and spool your email should your server go down. It's much better than putting together your own solution which could also go down (like if you have an extended internet ...
As per the RFC 2821, an NDR has to be sent to the "reverse-path" address specified with the MAIL FROM: command during the SMTP dialogue:
If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" ...
Use postqueue -f as root to flush the entire queue; this will cause delivery to be re-tried.
If the remote server really reports a 550, then the messages will not be deferred; they will be rejected, and your postfix server will instantly bounce them.
If this does not seem to be happening, make sure you do not have soft_bounce = yes set:
In the log you posted:
Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command))
The previous owner of your IP address sent junk mail from it, and Hotmail has banned it.
Try putting your IP ...
The return path for bounces is determined by the envelope sender (the MAIL FROM line in the smtp protocol). In the mail headers this is generally copied to the Return-Path header. Here's an example of a mailing list mail that specifies bounces should go to the mailing list server instead of the sender of the mail:
We got bounce message from 220.127.116.11. But why does it bounce to both email@example.com and firstname.lastname@example.org? Did they both send an email, which could not be delivered? Unlikely.
It isn't bouncing to the two addresses, it's bouncing it to postmaster telling you that delivery to those two addresses failed.
Then google replies with "421-4.7.0 [16.19....
If your email server is configured properly, you should reject email to unknown users during the SMTP transaction.
Reject Email During the SMTP Transaction
Your server should be configured to reject email to unknown users during the SMTP transaction phase. Doing so returns a 550 SMTP error code to the sending server. Since this happens during the SMTP ...
You cannot compel others to filter their incoming mail based on SPF and DKIM, or indeed any other criteria at all. If google chooses to ignore SPF, so be it; you've done your bit, all you can do now is sit tight and ignore any complaints from people who don't filter on SPF.
That said, having a valid SPF record does tend to reduce backscatter, because a ...
The problem seems to be that you have other servers than your mail server listed in your MX record, one of which has a lower priority. MX records work on a lowest-priority-first basis, which means the internet is first of all trying to send mail for your domain to smtp.secureserver.net., which doesn't seem to know anything about your domain. At this point, ...
Do I need to place that text in quotes ""?
The missing quotes should be the problem indeed, as explained e.g. in Record Types Supported:
Unlike with most other record types, for TXT records the Data field is
essentially free-form and may even include spaces. Please note: When
entering a string that includes spaces, such as SPF records, you must
Yes it is possible to send to mailbox@ip, if you want to strictly conform to the RFCs, then supporting this is required. But in this day and age it is extremely common for this to not be supported.
If you want to strictly follow the RFCs you will have an abuse and postmaster accounts that are read by a human. But if you actually have these accounts and ...
Although technically this is a grey-area my own view on this is far more black and white.
Ultimately you're running out of IPs because you're targetting emails to people who don't want them, they're complaining and thus the IPs are being removed from your options.
There's no real technical way around this, other than moving email provider anyway but even ...