Being blocked with error 554 5.7.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Being blocked with error 554 5.7.1

Julian Pilfold-Bagwell
Hi All,

I have a problem that's sprung to light after we bought in a 3rd party
cloud provider.  I have postfix 2.10 running on Centos 7 (main.cf below)
and our 3rd party provider is relaying mail out via our server, using
authentication on a legit account.  However, the recipient ISPs reject
mail with the error 554 5.7.1 recipient access denied, although this
doesn't seem to happen on all the messages that are being sent.  If
we're sending say 60 messages, the first block of 20 will go through,
the next 20 will be blocked and the final 20 will go through.  I'm
guessing that the receiving end is objecting to something in the headers
from the relayed mail, but can't quite get to grips as to why it occurs
in batches.

The 3rd party provider is sending reports to all of our end users which
is over a thousand emails+  so I've limited the delivery rate to 1
message per domain every twenty seconds  to try to appear less spammy
but it still happens as described.  The error message is as below:

NOQUEUE: reject: RCPT from smtp.overnetdata.com[5.153.65.228]: 554 5.7.1
<[hidden email]>: Recipient address rejected: Access denied;
from=<[hidden email]> to=<[hidden email]>
proto=ESMTP helo=<www7>

and we're receiving this from talktalk.co.uk, sky.com, yahoo.co.uk,
hotmail.com, outlook.com and gmail.com sometimes talks to us, and
sometimes doesn't.

and main.cf is shown here:

soft_bounce = no
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix

myhostname = mail.bordengrammar.kent.sch.uk
myorigin = $mydomain
inet_interfaces = 192.168.10.64, localhost
mydestination = $myhostname, localhost.$mydomain, localhost,
bordengrammar.kent.sch.uk
local_recipient_maps = hash:/etc/postfix/recipient-table
unknown_local_recipient_reject_code = 550
mynetworks = 192.168.10.0/22, 192.168.0.0/21, 127.0.0.0/8, localhost
alias_maps = hash:/etc/aliases
mailbox_transport = cyrus

smtpd_sasl_type = cyrus
smtpd_sasl_path = /etc/sasl2/smtpd.conf
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

smtpd_delay_reject = yes
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_restriction_classes = restricted_list

smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
check_recipient_access hash:/etc/postfix/rules/restricted_list
permit_sasl_authenticated permit_mynetworks reject_unauth_destination
reject_rbl_client sbl.spamhaus.org reject_rbl_client cbl.abuseat.org
reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client bl.spamcop.net

restricted_list = check_sender_access
hash:/etc/postfix/rules/restricted_sender,reject

readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail
html_directory = no
setgid_group = postdrop
manpage_directory = /usr/share/man
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
queue_directory = /var/spool/postfix
mail_owner = postfix
header_checks = pcre:/etc/postfix/rules/header_checks.pcre
mime_header_checks = regexp:/etc/postfix/mime_header_checks
masquerade_domains = $mydomain
content_filter = amavisd-new:[127.0.0.1]:10024
content_filter = amavisd:[127.0.0.1]:10024
data_directory = /var/lib/postfix
inet_protocols = ipv4

smtpd_error_sleep_time = 1s
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20

smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 20s
smtp_extra_recipient_limit = 10

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated
permit_inet_interfaces reject_unknown_reverse_client_hostname
smtpd_tls_auth_only = no
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

enable_original_recipient = no
message_size_limit = 51200000
mailbox_size_limit = 102400000
default_destination_concurrency_limit = 10


We also use postfwd to rate limit but for this, I've temporarily
disabled the rules while testing.

Does anyone have any suggestions as to how I can get around this one?

Thanks,

Jools

--
J. Pilfold-Bagwell,
Network Manager,
Borden Grammar School.


This email is from Borden Grammar School Trust.

This email, together with any files transmitted with it, is
confidential, and is intended solely for the use of the individual or
entity to whom it is addressed. Any unauthorised dissemination or
copying of this email or its attachments, and any use or disclosure of
any information contained in them, is strictly prohibited, and may also
be illegal. If you are not the intended recipient you may not use,
disclose, distribute, copy, print or relay this email.

Please note that any views expressed by an individual within this
email, do not necessarily reflect the views of the Borden Grammar
School Trust.

Borden Grammar School Trust has taken reasonable precautions to ensure
no viruses are present in this email.  The Academy cannot accept
responsibility for any loss or damage arising from the use of this
email and/or files attached.

Registered Office: Borden Grammar School, Avenue of Remembrance,
Sittingbourne, Kent ME10 4DB

Registered in England: 07827591

Reply | Threaded
Open this post in threaded view
|

Re: Being blocked with error 554 5.7.1

Dominic Raferd
Interesting. Your off-list reply to mine was bounced by Google (when
our server relayed it). You wrote:

> The from header is:
> edulink<at>bordengrammar.kent.sch.uk
> however they've set a non-existent account as the reply to...

Those look fine to me.

But why was your message to me bounced by Google? Their bounce
response reads: 'Our system has detected that this message is
suspicious due to the nature of the content and/or the links within.
To best protect our users from spam, the message has been blocked.
Please visit https://support.google.com/mail/answer/188131 for more
information.'

You can read what Google say at that link. There is nothing in your
email that looks at all like spam to me.

Are you able to fix the DMARC entry in your DNS? It has spurious escaped quotes.

On Sat, 12 Sep 2020 at 12:15, Dominic Raferd <[hidden email]> wrote:

>
> On Fri, 11 Sep 2020 at 22:49, Julian Pilfold-Bagwell
> <[hidden email]> wrote:
> >
> > I have a problem that's sprung to light after we bought in a 3rd party
> > cloud provider.  I have postfix 2.10 running on Centos 7 (main.cf below)
> > and our 3rd party provider is relaying mail out via our server, using
> > authentication on a legit account.  However, the recipient ISPs reject
> > mail with the error 554 5.7.1 recipient access denied, although this
> > doesn't seem to happen on all the messages that are being sent.  If
> > we're sending say 60 messages, the first block of 20 will go through,
> > the next 20 will be blocked and the final 20 will go through.  I'm
> > guessing that the receiving end is objecting to something in the headers
> > from the relayed mail, but can't quite get to grips as to why it occurs
> > in batches.
> >
> > The 3rd party provider is sending reports to all of our end users which
> > is over a thousand emails+  so I've limited the delivery rate to 1
> > message per domain every twenty seconds  to try to appear less spammy
> > but it still happens as described.  The error message is as below:
> >
> > NOQUEUE: reject: RCPT from smtp.overnetdata.com[5.153.65.228]: 554 5.7.1
> > <[hidden email]>: Recipient address rejected: Access denied;
> > from=<[hidden email]> to=<[hidden email]>
> > proto=ESMTP helo=<www7>
> >
> > and we're receiving this from talktalk.co.uk, sky.com, yahoo.co.uk,
> > hotmail.com, outlook.com and gmail.com sometimes talks to us, and
> > sometimes doesn't.
> >
> > and main.cf is shown here:...
>
> The setup seems imperfect, and the version of postfix rather old, but
> which if any of the imperfections is causing this new problem is hard
> to say without fuller examples of what is being blocked, which I can
> well understand you might not want to post on an open forum. My
> observations are:
>
> Instead of 'smtp_use_tls = yes' it is advisable to use
> 'smtp_tls_security_level = may' (Postfix 2.3+)
>
> Your SPF entry in DNS looks ok, provided as you say that the 3rd party
> is sending your emails via your mail server and not independently.
> Also your mail server's ip is not blacklisted at any of the 129 rbls I
> regularly check, nor at https://ipremoval.sms.symantec.com/. You can
> check its status with Microsoft by registering it at their Smart
> Network Data Service.
>
> Your DMARC entry in DNS is broken, also you do not appear to be
> signing outgoing emails with DKIM. But I doubt either of these is the
> explanation for your problem.
>
> Is the third party sender using your domain in the 'From:' header as
> well as in the envelope?
Reply | Threaded
Open this post in threaded view
|

Re: Being blocked with error 554 5.7.1

David Bürgin
Dominic Raferd:
> Are you able to fix the DMARC entry in your DNS? It has spurious escaped quotes.

The SPF record is invalid, too, ‘a:81.145.130.2’ is not valid syntax.
Perhaps these add to some negative score for your messages.
Reply | Threaded
Open this post in threaded view
|

Re: Being blocked with error 554 5.7.1

Dominic Raferd
In reply to this post by Julian Pilfold-Bagwell
Jools, as David Burgin pointed out, your SPF record in DNS is (still)
broken (as well as your DMARC record) and this may well be the cause
of your problems.

v=spf1 mx a:81.145.130.2 -all
should be (because the 'a:...' syntax is wrong and superfluous):
v=spf1 mx -all
- I missed this on my original reading oops

For the DMARC record, remove the escaped quotes:
\"v=DMARC1; p=none; rua=mailto:[hidden email]\"
should be:
v=DMARC1; p=none; rua=mailto:[hidden email]


On Sat, 12 Sep 2020 at 19:17, Julian Pilfold-Bagwell
<[hidden email]> wrote:

>
> Hi,
>
> I've fixed DKIM and have fired a message off to several DKIM validation
> sites which have come back with SPF, DMARC and DKIM as all having
> passed.   I changed the TLS setting you suggested as well
>
> We then sent a test batch and the first 11 went through, the following 8
> were rejected, and the next 7 went through.
>
> It really is weird.  If it was all of the messages being bounced I could
> understand it, but google and yahoo both seem to let a load through yet
> block a handful.  I guess it's possible that the end-users have an
> option to set the aggressiveness of the spam filtering but it seems like
> a setting that wouldn't be commonly used as Google's defaults are
> usually pretty good and we don't tend to get rejected in daily use.
>
>
> On 12/09/2020 14:53, Dominic Raferd wrote:
> > Just after I sent my reply to your later email I saw this reply of
> > yours (below) - which Google had accepted but put into my spam folder!
> >
> > On Sat, 12 Sep 2020 at 13:14, Julian Pilfold-Bagwell
> > <[hidden email]> wrote:
> >>    I'll make the change to TLS and see what happens as well as fix the
> >> DMARC.  The server's been running 24/7 since 2015 and is due for
> >> replacement in the summer of 2021 at which point I'll be upgrading the
> >> postfix version.
> >>
> >> I'll check the headers again and will get back.
> >>
> >> On 12/09/2020 12:15, Dominic Raferd wrote:
> >>> On Fri, 11 Sep 2020 at 22:49, Julian Pilfold-Bagwell
> >>> <[hidden email]> wrote:
> >>>> I have a problem that's sprung to light after we bought in a 3rd party
> >>>> cloud provider.  I have postfix 2.10 running on Centos 7 (main.cf below)
> >>>> and our 3rd party provider is relaying mail out via our server, using
> >>>> authentication on a legit account.  However, the recipient ISPs reject
> >>>> mail with the error 554 5.7.1 recipient access denied, although this
> >>>> doesn't seem to happen on all the messages that are being sent.  If
> >>>> we're sending say 60 messages, the first block of 20 will go through,
> >>>> the next 20 will be blocked and the final 20 will go through.  I'm
> >>>> guessing that the receiving end is objecting to something in the headers
> >>>> from the relayed mail, but can't quite get to grips as to why it occurs
> >>>> in batches.
> >>>>
> >>>> The 3rd party provider is sending reports to all of our end users which
> >>>> is over a thousand emails+  so I've limited the delivery rate to 1
> >>>> message per domain every twenty seconds  to try to appear less spammy
> >>>> but it still happens as described.  The error message is as below:
> >>>>
> >>>> NOQUEUE: reject: RCPT from smtp.overnetdata.com[5.153.65.228]: 554 5.7.1
> >>>> <[hidden email]>: Recipient address rejected: Access denied;
> >>>> from=<[hidden email]> to=<[hidden email]>
> >>>> proto=ESMTP helo=<www7>
> >>>>
> >>>> and we're receiving this from talktalk.co.uk, sky.com, yahoo.co.uk,
> >>>> hotmail.com, outlook.com and gmail.com sometimes talks to us, and
> >>>> sometimes doesn't.
> >>>>
> >>>> and main.cf is shown here:...
> >>> The setup seems imperfect, and the version of postfix rather old, but
> >>> which if any of the imperfections is causing this new problem is hard
> >>> to say without fuller examples of what is being blocked, which I can
> >>> well understand you might not want to post on an open forum. My
> >>> observations are:
> >>>
> >>> Instead of 'smtp_use_tls = yes' it is advisable to use
> >>> 'smtp_tls_security_level = may' (Postfix 2.3+)
> >>>
> >>> Your SPF entry in DNS looks ok, provided as you say that the 3rd party
> >>> is sending your emails via your mail server and not independently.
> >>> Also your mail server's ip is not blacklisted at any of the 129 rbls I
> >>> regularly check, nor at https://ipremoval.sms.symantec.com/. You can
> >>> check its status with Microsoft by registering it at their Smart
> >>> Network Data Service.
> >>>
> >>> Your DMARC entry in DNS is broken, also you do not appear to be
> >>> signing outgoing emails with DKIM. But I doubt either of these is the
> >>> explanation for your problem.
> >>>
> >>> Is the third party sender using your domain in the 'From:' header as
> >>> well as in the envelope?
> >> --
> >> J. Pilfold-Bagwell,