Jeffry Dwight wrote:
Today I noticed the following response from GMail after submission of email:
421-4.7.0 [x.x.x.x 15] Our system has detected that this message is
421-4.7.0 suspicious due to the nature of the content and/or the links within.
421-4.7.0 To best protect our users from spam, the message has been blocked.
421-4.7.0 Please visit
4.7.0 https://support.google.com/mail/answer/188131 for more information.
f77si267316oig.47 - gsmtp
Contrary to what 421 means generally ("try again later"), and contrary to
GMail's own documentation page
https://support.google.com/a/answer/3726730?hl=en
where it says that 421 4.7.0 means "Try again later, closing connection"
I find that trying again later always results in the same code, and it's
therefore a permanent failure like 5xx would be. The particular email I saw in
the logs was a newsletter from a publisher to an author, with links to new
releases. Spammy in nature, maybe, but certainly solicited, and nothing really
out of the ordinary.
I noticed it only because our system saw the 421 code and dutifully kept
requeuing for retry until the max number of attempts had been reached.
Which is exactly what you should do.
Am I misunderstanding what 421 means after DATA or BDAT, or is GMail replying
with the wrong code? Surely if it means to reject the email out of hand, it
should say so, shouldn't it?
Quite possibly neither of you are wrong. That said, you don't know why
Google are 421'ing it so you don't know whether is is a temporary error
or not.
We currently treat a 5xx reply after DATA or BDAT as a permanent failure, and
don't retry. We treat 4xx replies after DATA or BDAT as temporary, and queue for
retry. How should we handle it?
I would suggest you are doing the 100% correct thing.
The most common reason for a 421 after DATA I would expect to be an
'over quota' error - which if you're not supplying the size earlier this
would be an expected possibility. The reason for it continuing to fail
would be for example the account owner not logging in and cleaning up
some space for a longer period of time than your queue/retry time. As
it is quite allowable in the RFCs/BCPs to set your own retry times/plans
adjust your settings as you deem appropriate.
The other problem with continuous 421's is of course if the other end
has a reason which is based not on a user resolvable event, for example
(and probably a bad one) if a REGEX rule matches and says, "This might
be/contain a virus/malware" ... but then not having a method of
bypassing that rule in future attempts if the message is determined as
being clean or actually bad and therefore providing alternative
permanent messages (whether 2xx or 5xx as appropriate.) This is of
course a problem with the receivers setup however as an external party
you have no-idea so you have to resort to adjusting your queue time as
appropriate for you.
Regards,
Michelle
--
Michelle Sullivan
http://www.mhix.org/
_______________________________________________
mailop mailing list
[email protected]
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
