What's a better error code than 554 to get a sending server to stop retrying?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

What's a better error code than 554 to get a sending server to stop retrying?

robgane
I have a milter set up to REJECT on some body content.

It works like it should and REJECTS with the message

        Jul 25 14:41:13 mariner postfix/handoff/smtpd[56542]: proxy-reject: END-OF-MESSAGE: 554 5.7.1 id=12969-07 - Rejected by next-hop MTA on relaying, from MTA(smtp:[127.0.0.1]:16002): 554 5.7.1 BANNED CONTENT; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<mail123.EXAMPLE1.com>

I've tested it by sending 'bad' email to myself from gmail.  Seems to work as advertised.

The mailers on EXAMPLE2.com are for an otherwise fairly repsectable domain.  Most of what comes from there to me is OK.

But they keep retrying to resend the email that's getting REJECTed.  Every 15mins for the past 9+ hours since the 1st message was sent and got rejected.

Depending on where I read about it that "554 5.7.1" error code means "failed transaction".

I thought that a REJECT is supposed to do that -- just send an 'undeliverable' notice back to the sender containing the error code.

But it acts like it means "and retry later" too.

Is there some other Error code that says "failed.  permanently.  stop trying to resend the darn thing." ?

Or if not a better way to deal with it in Postfix?

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What's a better error code than 554 to get a sending server to stop retrying?

Wietse Venema
[hidden email]:
> But they keep retrying to resend the email that's getting REJECTed.
> Every 15mins for the past 9+ hours since the 1st message was sent
> and got rejected.

RFC 5321, the definition of SMTP says:

4.2.1.  Reply Code Severities and Theory
   ...
5yz  Permanent Negative Completion reply
   The command was not accepted and the requested action did not
   occur.  The SMTP client SHOULD NOT repeat the exact request (in
   the same sequence).

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What's a better error code than 554 to get a sending server to stop retrying?

Kevin A. McGrail
In reply to this post by robgane
On 7/25/2017 5:51 PM, [hidden email] wrote:
> Depending on where I read about it that "554 5.7.1" error code means "failed transaction".
Unfortunately, you might need logic to accept and silently discard. We
do this, for example, with viruses to avoid blowback.

Regards,
KAM
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What's a better error code than 554 to get a sending server to stop retrying?

/dev/rob0
> On 7/25/2017 5:51 PM, [hidden email] wrote:
> >Depending on where I read about it that "554 5.7.1" error code
> >means "failed transaction".

554 is described in RFC 5321, yes, as "failed transaction".

5.7.1 is an Extended Mail System Status Code, described in RFC 3463:

https://tools.ietf.org/html/rfc3463#section-3.8

It means "message refused" for policy or security reasons.

Since spam zombies usually cannot heed a server's response, it does
not matter what error code you give them.

A normal MTA will consider "5xx 5.x.x" a permanent error, and will
not retry.  Exception: see soft_bounce:

http://www.postfix.org/postconf.5.html#soft_bounce

On Tue, Jul 25, 2017 at 07:07:18PM -0400, Kevin A. McGrail wrote:
> Unfortunately, you might need logic to accept and silently discard.
> We do this, for example, with viruses to avoid blowback.

Oh, I disagree.  The best thing to do is to reject anything you're
unwilling/unable to deliver.  You're not causing any bounces; if a
connecting client does generate a bounce for your rejection that is
THEIR problem; or in the case of a human sender, that is the way to
avoid mail loss.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What's a better error code than 554 to get a sending server to stop retrying?

Kevin A. McGrail
On 7/25/2017 7:42 PM, /dev/rob0 wrote:
> Oh, I disagree.  The best thing to do is to reject anything you're
> unwilling/unable to deliver.  You're not causing any bounces; if a
> connecting client does generate a bounce for your rejection that is
> THEIR problem; or in the case of a human sender, that is the way to
> avoid mail loss.

We can debate RFC's all day but the reality is that we are dealing with
people not following the RFCs like spambots.  They will just retry and
if you do any type of queue and check, then you can cause backscatter, etc.

My advice remains the same if you have mail you are giving a 5xx that is
retrying.  Giving it a 5xx is the correct answer.  If that doesn't work,
you will find you need to 2xx it and silently discard.

As mentioned, we do this for viruses in particularly to rid the world of
them.  I'm sure it breaks an RFC in letter but not in spirit as it's my
job to avoid viruses getting through and sometimes they are looking for
blowback messages to carry the payload.

Regards,
KAM
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

accept+discard vs. reject (was: Re: What's a better error code ...)

/dev/rob0
On Tue, Jul 25, 2017 at 07:49:32PM -0400, Kevin A. McGrail wrote:
> On 7/25/2017 7:42 PM, /dev/rob0 wrote:

>> On Tue, Jul 25, 2017 at 07:07:18PM -0400, Kevin A. McGrail wrote:
>>> Unfortunately, you might need logic to accept and silently
>>> discard. We do this, for example, with viruses to avoid blowback.

> >Oh, I disagree.  The best thing to do is to reject anything you're
> >unwilling/unable to deliver.  You're not causing any bounces; if a
> >connecting client does generate a bounce for your rejection that
> >is THEIR problem; or in the case of a human sender, that is the
> >way to avoid mail loss.
>
> We can debate RFC's all day

I am not talking about RFCs; I am talking about responsible mail
handling.

> but the reality is that we are dealing
> with people not following the RFCs like spambots.

A direct-to-MX zombie, the likes of which comprise the vast majority
of our postscreen connections, is not going to cause anyone any
blowback.  The only harm in reject vs. accept/discard is for your
Internet connection provider, because they can't bill you for
exceeding your bandwidth allowance. :)

Real MTAs relaying for a zombie most certainly should be rejected;
perhaps it's the only way the admin can find out about, and fix, the
problem.

> They will just retry and if you do any type of queue and check,
> then you can cause backscatter, etc.

I certainly was not talking about accept-then-bounce, nor was the OP,
unless I misunderstood the post.  The previous $Subject would tend to
indicate it was about rejection, not bounces.

> My advice remains the same if you have mail you are giving a 5xx
> that is retrying.  Giving it a 5xx is the correct answer.

Okay, we are good up to that point.

> If that doesn't work, you will find you need to 2xx it and
> silently discard.

Fortunately that advice, with which I disagree, is difficult to
implement in Postfix.  It's in fact not possible, without a policy
service external to Postfix.

> As mentioned, we do this for viruses in particularly to rid the
> world of them.

Thanks, but I don't think it is working. :)

> I'm sure it breaks an RFC in letter but not in spirit as it's my
> job to avoid viruses getting through and sometimes they are looking
> for blowback messages to carry the payload.

I am curious, what kind of logic do you have to determine that a
spamming client might be a backscatterer?  Are you talking about a
custom policy service, or a milter?
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: accept+discard vs. reject

Kevin A. McGrail
On 7/25/2017 8:48 PM, /dev/rob0 wrote:
> I am curious, what kind of logic do you have to determine that a
> spamming client might be a backscatterer?  Are you talking about a
> custom policy service, or a milter?

For the record, I can agree to disagree as I respect and understand your
position.  I just choose to do it differently and think others should as
well.

But yes, I use a milter.  I am a fanboy of MIMEDefang.

For example, in his case, I have a REDIS backend and would store message
IDs if I give a 5xx.  Then if I see the same message id retried, you
could do the 2xx+silent discard.

Regards,
KAM
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: accept+discard vs. reject

/dev/rob0
On Tue, Jul 25, 2017 at 09:02:17PM -0400, Kevin A. McGrail wrote:

> On 7/25/2017 8:48 PM, /dev/rob0 wrote:
> >I am curious, what kind of logic do you have to determine that a
> >spamming client might be a backscatterer?  Are you talking about a
> >custom policy service, or a milter?
>
> For the record, I can agree to disagree as I respect and understand
> your position.  I just choose to do it differently and think others
> should as well.
>
> But yes, I use a milter.  I am a fanboy of MIMEDefang.
>
> For example, in his case, I have a REDIS backend and would store
> message IDs if I give a 5xx.  Then if I see the same message id
> retried, you could do the 2xx+silent discard.

Ah, okay.  It seems we are looking at this from totally different
angles.  My rejections are pre-DATA, so there is no Message-ID to
record.

I would still be curious to know (back to what the OP was asking) if
this strategy of accept+discard is actually making the zombies go
away ... I wouldn't think so.  But this is probably not all that
relevant to Postfix, at this point.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What's a better error code than 554 to get a sending server to stop retrying?

Kris Deugau
In reply to this post by robgane
[hidden email] wrote:

> I have a milter set up to REJECT on some body content.
>
> It works like it should and REJECTS with the message
>
> Jul 25 14:41:13 mariner postfix/handoff/smtpd[56542]: proxy-reject: END-OF-MESSAGE: 554 5.7.1 id=12969-07 - Rejected by next-hop MTA on relaying, from MTA(smtp:[127.0.0.1]:16002): 554 5.7.1 BANNED CONTENT; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<mail123.EXAMPLE1.com>
>
> I've tested it by sending 'bad' email to myself from gmail.  Seems to work as advertised.
>
> The mailers on EXAMPLE2.com are for an otherwise fairly repsectable domain.  Most of what comes from there to me is OK.
>
> But they keep retrying to resend the email that's getting REJECTed.  Every 15mins for the past 9+ hours since the 1st message was sent and got rejected.
>
> Depending on where I read about it that "554 5.7.1" error code means "failed transaction".
>
> I thought that a REJECT is supposed to do that -- just send an 'undeliverable' notice back to the sender containing the error code.
>
> But it acts like it means "and retry later" too.
>
> Is there some other Error code that says "failed.  permanently.  stop trying to resend the darn thing." ?

Any 5xx code is supposed to say that.  Whether the recipient of the
remote site's resulting bounce message is paying attention is another
matter.

You're now down to something like Kevin McGrail's suggestion downthread,
or contacting the postmaster at the remote site to get them to check in
to this from their end.

If that fails (ie, no action;  or worse, postmaster@ and/or abuse@
bounces), you may need to resort to a firewall entry, and live without
the legitimate traffic for that site.  (I've done this once in a while -
all it really did was clean up my logs a little, because when I removed
the block months later the problem traffic came right back.)  That
assumes there's not much of that;  if you get a lot of legitimate mail
from that site, plus this trickle of mishandled rejections, you're out
of local options.

This could also be a sender that just keeps trying to send the same
thing over and over again, an automated process doing the same, or even
virus-generated mail not being caught by whatever outbound filtering the
remote site has.

-kgd
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What's a better error code than 554 to get a sending server to stop retrying?

robgane
> Any 5xx code is supposed to say that

That's clear now that's how it's supposed to work.


> Whether the recipient of the remote site's resulting bounce message is paying attention is another
matter.

That's the actual problem here I think.

> You're now down to something like Kevin McGrail's suggestion downthread,

I get the idea of it.

The "how to do it" in Postfix without 'Mimedefang + REDIS' or something like it is a different story.

> or contacting the postmaster at the remote site to get them to check in
to this from their end. If that fails (ie, no action;  or worse, postmaster@ and/or abuse@
bounces),

I'm in the "no action" column.

> if you get a lot of legitimate mail from that site, plus this trickle of mishandled rejections

I do

> you're out of local options.

That was the original hope -- to get something to fight back with just in Postfix.

The sending mail server is at a pretty big "mail services" provider.  Which mainly looks like "marketing" services if you ask me.

A non local option is to contact the ORIGINAL sender and tell them to get me off their $&$&^$ mailings or get blocked completely.

I don't believe for one second that they actually care.  But it'll make me feel like I did something.

> This could also be a sender that just keeps trying to send the same
thing over and over again, an automated process doing the same

The fact that it's evenly timed, every 15 mins, says 'automated' to me

Thanks all for the comments.

Rob
Loading...