Relay server bounce question

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

Relay server bounce question

Jay Deiman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm running a backup MX server and I've noticed something I find a
little odd.  When the recipient mail server denies a transaction from
the backup MX server with a 5XX, the backup MX server defers the mail
instead of immediately bouncing it.  Is there any way to change this
behavior so that if it gets denied with a 5XX, it will immediately
bounce it, but, obviously, defer it on a 4XX?

Thanks,

Jay Deiman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIUxs6Q0lr+ZVKSBgRAjRuAJ93f6yxX8S/IdZ91NQ9Hdgopykj0QCeMR1E
XyOLO7jYjRw0ca7aBYbxYao=
=8d/4
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Jay Deiman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jay wrote:
| I'm running a backup MX server and I've noticed something I find a
| little odd.  When the recipient mail server denies a transaction from
| the backup MX server with a 5XX, the backup MX server defers the mail
| instead of immediately bouncing it.  Is there any way to change this
| behavior so that if it gets denied with a 5XX, it will immediately
| bounce it, but, obviously, defer it on a 4XX?
|
| Thanks,
|
| Jay Deiman

Oops, sorry about the double post.

Jay
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIUyGLQ0lr+ZVKSBgRAsb8AKCYGqlQPRIW8Xeg2OkTsd2jIS9npgCgkndL
Od0fMi4pgiKOr72JKJk5Gp0=
=42Rq
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Wietse Venema
In reply to this post by Jay Deiman
Jay:
-- Start of PGP signed section.
> I'm running a backup MX server and I've noticed something I find a
> little odd.  When the recipient mail server denies a transaction from
> the backup MX server with a 5XX, the backup MX server defers the mail
> instead of immediately bouncing it.  Is there any way to change this
> behavior so that if it gets denied with a 5XX, it will immediately
> bounce it, but, obviously, defer it on a 4XX?

The description is not clear.

See mailing list welcome message.

        Wietse

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Noel Jones-2
In reply to this post by Jay Deiman
Jay wrote:

> I'm running a backup MX server and I've noticed something I find a
> little odd.  When the recipient mail server denies a transaction from
> the backup MX server with a 5XX, the backup MX server defers the mail
> instead of immediately bouncing it.  Is there any way to change this
> behavior so that if it gets denied with a 5XX, it will immediately
> bounce it, but, obviously, defer it on a 4XX?
>
> Thanks,
>
> Jay Deiman

A couple of observations...

If you're running a backup MX server, the recipient system
should never reject mail you have already accepted.  This
makes you a backscatter source and eventually you'll get
blacklisted.
In particular, the backup MX must have a list of valid
recipients, and any spam filtering done on the recipient
system must not reject the mail - it must either be tagged,
quarantined, or discarded at that point.
http://www.backscatterer.org/?target=backscatter

Postfix won't defer mail rejected with a 5xx code unless you
have set soft_bounce=yes somewhere in your configuration.  The
soft_bounce feature is intended for testing and shouldn't be
used on a production system.

It's now generally accepted that backup MX servers are more
trouble than they're worth.  If you must have more than one MX
for load handling or (marginally) increased reliability, make
sure all the MXs are configured identically and especially
make sure they will reject undeliverable recipients during the
original SMTP transaction.

If you need more help, we need more details of what you expect
to happen vs. what is actually happening, including "postconf
-n" output and logging showing the undesired behavior.
http://www.postfix.org/DEBUG_README.html#mail

--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Jay Deiman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noel Jones wrote:
| Jay wrote:
|> I'm running a backup MX server and I've noticed something I find a
|> little odd.  When the recipient mail server denies a transaction from
|> the backup MX server with a 5XX, the backup MX server defers the mail
|> instead of immediately bouncing it.  Is there any way to change this
|> behavior so that if it gets denied with a 5XX, it will immediately
|> bounce it, but, obviously, defer it on a 4XX?
|>
|> Thanks,
|>
|> Jay Deiman
|
| A couple of observations...
|
| If you're running a backup MX server, the recipient system should never
| reject mail you have already accepted.  This makes you a backscatter
| source and eventually you'll get blacklisted.
| In particular, the backup MX must have a list of valid recipients, and
| any spam filtering done on the recipient system must not reject the mail
| - it must either be tagged, quarantined, or discarded at that point.
| http://www.backscatterer.org/?target=backscatter
|
| Postfix won't defer mail rejected with a 5xx code unless you have set
| soft_bounce=yes somewhere in your configuration.  The soft_bounce
| feature is intended for testing and shouldn't be used on a production
| system.
|
| It's now generally accepted that backup MX servers are more trouble than
| they're worth.  If you must have more than one MX for load handling or
| (marginally) increased reliability, make sure all the MXs are configured
| identically and especially make sure they will reject undeliverable
| recipients during the original SMTP transaction.

Let me make this a bit more clear.  I work for an ISP and we provide
backup MX service for some of our customers.  This was in place years
before I started there.  I am in full agreement that backup MX is not
even really necessary, and in this case, it's actually an all around bad
idea.  I and another co-worker are pushing to get our product dept. to
require lists of valid email addresses for the domains we are doing this
for so that, at least going forward, we would be able to correctly
reject messages.  Unfortunately for the hundreds of domains we already
have in the system, it's an issue.  I'm fully aware of the backscatter
issues here too and we are working on hacks to try to get around this,
but it's a bad situation, no way around that.

The issue we are having is that a lot of the customer mail servers are
just "spam filter appliances" and many of the people that "administer"
these machines don't even know what a whitelist is.  I'm basically
trying to make the best of a bad situation.  Currently the cluster of
machines doing the actual backup will relay any bounces to another
machine with a very short queue lifetime.

I think I have found a solution to force the bouncing of in queue
messages, so a simple script running on a cron will be able to do the
job without having to do too much interaction.

Thanks for all the help everyone,

Jay Deiman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIVBEVQ0lr+ZVKSBgRAu45AJ0UFJIN7w1aMV3AH4in825+9qmVdgCeMSuk
P6JC4y+A9FiIGkqWZF+eiKw=
=rIxu
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Noel Jones-2
Jay Deiman wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Noel Jones wrote:
> | Jay wrote:
> |> I'm running a backup MX server and I've noticed something I find a
> |> little odd.  When the recipient mail server denies a transaction from
> |> the backup MX server with a 5XX, the backup MX server defers the mail
> |> instead of immediately bouncing it.  Is there any way to change this
> |> behavior so that if it gets denied with a 5XX, it will immediately
> |> bounce it, but, obviously, defer it on a 4XX?
> |>
> |> Thanks,
> |>
> |> Jay Deiman
> |
> | A couple of observations...
> |
> | If you're running a backup MX server, the recipient system should never
> | reject mail you have already accepted.  This makes you a backscatter
> | source and eventually you'll get blacklisted.
> | In particular, the backup MX must have a list of valid recipients, and
> | any spam filtering done on the recipient system must not reject the mail
> | - it must either be tagged, quarantined, or discarded at that point.
> | http://www.backscatterer.org/?target=backscatter
> |
> | Postfix won't defer mail rejected with a 5xx code unless you have set
> | soft_bounce=yes somewhere in your configuration.  The soft_bounce
> | feature is intended for testing and shouldn't be used on a production
> | system.
> |
> | It's now generally accepted that backup MX servers are more trouble than
> | they're worth.  If you must have more than one MX for load handling or
> | (marginally) increased reliability, make sure all the MXs are configured
> | identically and especially make sure they will reject undeliverable
> | recipients during the original SMTP transaction.
>
> Let me make this a bit more clear.  I work for an ISP and we provide
> backup MX service for some of our customers.  This was in place years
> before I started there.  I am in full agreement that backup MX is not
> even really necessary, and in this case, it's actually an all around bad
> idea.  I and another co-worker are pushing to get our product dept. to
> require lists of valid email addresses for the domains we are doing this
> for so that, at least going forward, we would be able to correctly
> reject messages.  Unfortunately for the hundreds of domains we already
> have in the system, it's an issue.  I'm fully aware of the backscatter
> issues here too and we are working on hacks to try to get around this,
> but it's a bad situation, no way around that.
>
> The issue we are having is that a lot of the customer mail servers are
> just "spam filter appliances" and many of the people that "administer"
> these machines don't even know what a whitelist is.  I'm basically
> trying to make the best of a bad situation.  Currently the cluster of
> machines doing the actual backup will relay any bounces to another
> machine with a very short queue lifetime.
>
> I think I have found a solution to force the bouncing of in queue
> messages, so a simple script running on a cron will be able to do the
> job without having to do too much interaction.
>
> Thanks for all the help everyone,
>
> Jay Deiman

I feel your pain...  Please forgive the beating.

Turning off soft_bounce should fix your problem.  Or show
"postconf -n" and log entries of the undesired behavior.

A script to force what should be happening anyway sounds like
a very bad solution.


--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Jay Deiman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

|> Let me make this a bit more clear.  I work for an ISP and we provide
|> backup MX service for some of our customers.  This was in place years
|> before I started there.  I am in full agreement that backup MX is not
|> even really necessary, and in this case, it's actually an all around bad
|> idea.  I and another co-worker are pushing to get our product dept. to
|> require lists of valid email addresses for the domains we are doing this
|> for so that, at least going forward, we would be able to correctly
|> reject messages.  Unfortunately for the hundreds of domains we already
|> have in the system, it's an issue.  I'm fully aware of the backscatter
|> issues here too and we are working on hacks to try to get around this,
|> but it's a bad situation, no way around that.
|>
|> The issue we are having is that a lot of the customer mail servers are
|> just "spam filter appliances" and many of the people that "administer"
|> these machines don't even know what a whitelist is.  I'm basically
|> trying to make the best of a bad situation.  Currently the cluster of
|> machines doing the actual backup will relay any bounces to another
|> machine with a very short queue lifetime.
|>
|> I think I have found a solution to force the bouncing of in queue
|> messages, so a simple script running on a cron will be able to do the
|> job without having to do too much interaction.
|>
|> Thanks for all the help everyone,
|>
|> Jay Deiman
|
| I feel your pain...  Please forgive the beating.
|
| Turning off soft_bounce should fix your problem.  Or show "postconf -n"
| and log entries of the undesired behavior.
|
| A script to force what should be happening anyway sounds like a very bad
| solution.

I agree for the most part.  soft_bounce is currently set to "no" in this
case.  That was the first thing that I thought of, but the behavior of
soft_bounce is actually different than what you are thinking of in this
situation.  soft_bounce, if on, would actually just change a 5XX code to
a 4XX code at the incoming SMTP transaction.  It doesn't make a
difference in this case because the message is accepted, put in the
queue, picked up and an attempt to send it to it's destination is made.
~ The destination is where the 5XX code is coming from.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIVBcLQ0lr+ZVKSBgRAjYuAJ9Hk2gPRuqXadoU1YV65k98KuLX1wCfRYKW
fskqKHbn0rr67ubvK/oBmuA=
=rtoG
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Noel Jones-2
Jay Deiman wrote:
> I agree for the most part.  soft_bounce is currently set to "no" in this
> case.  That was the first thing that I thought of, but the behavior of
> soft_bounce is actually different than what you are thinking of in this
> situation.  soft_bounce, if on, would actually just change a 5XX code to
> a 4XX code at the incoming SMTP transaction.  It doesn't make a
> difference in this case because the message is accepted, put in the
> queue, picked up and an attempt to send it to it's destination is made.
> ~ The destination is where the 5XX code is coming from.
>

I'm somewhat familiar with how soft_bounce works.  It can act
both on input (smtpd) and output (smtp).

soft_bounce can be set in master.cf on a specific transport to
prevent (actually just delay) bounces when mail cannot be
delivered through that transport.  In particular, folks have
been known to set soft_bounce=yes for the "relay" transport.

Check your master.cf for soft_bounce.  If it's not there,
either your postfix or your description of the problem is
severely screwed up.  Postfix won't keep mail in the queue
after a 5xx error unless soft_bounce turned on.

Good luck.

--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Relay server bounce question

Jay Deiman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noel Jones wrote:
| Jay Deiman wrote:
|> I agree for the most part.  soft_bounce is currently set to "no" in this
|> case.  That was the first thing that I thought of, but the behavior of
|> soft_bounce is actually different than what you are thinking of in this
|> situation.  soft_bounce, if on, would actually just change a 5XX code to
|> a 4XX code at the incoming SMTP transaction.  It doesn't make a
|> difference in this case because the message is accepted, put in the
|> queue, picked up and an attempt to send it to it's destination is made.
|> ~ The destination is where the 5XX code is coming from.
|>
|
| I'm somewhat familiar with how soft_bounce works.  It can act both on
| input (smtpd) and output (smtp).
|
| soft_bounce can be set in master.cf on a specific transport to prevent
| (actually just delay) bounces when mail cannot be delivered through that
| transport.  In particular, folks have been known to set soft_bounce=yes
| for the "relay" transport.
|
| Check your master.cf for soft_bounce.  If it's not there, either your
| postfix or your description of the problem is severely screwed up.
| Postfix won't keep mail in the queue after a 5xx error unless
| soft_bounce turned on.
|
| Good luck.
|

I found the answer to my problem here.  It is the
"smtp_skip_5xx_greeting" config option.  The endpoints that I'm having
trouble relaying to are replying with an immediate 5XX response.
smtp_skip_5xx_greeting is set to "yes" by default which makes Postfix
defer the mail when it encounters an immediate 5XX response from a
remote smtp server.  This is probably a good thing in 90+% of cases.  In
my case, it makes for big deferred queues.

Thanks for everyone's help in getting this figured out.

Jay Deiman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIWCBxQ0lr+ZVKSBgRAlATAJ9rXYpTcwYy6ZDfhV4w/dT9J2ZxAQCgmVXj
KVbitkF4WktN/td9XaUuQvg=
=LqKW
-----END PGP SIGNATURE-----