Hello,

We just started looking at the greet_pause feature. Right now,
greet_pause will return a 554 error code. Is there a way (without
modifying the source code) to change this to 454 so that the remote
server will queue the message and retry later?

Thanks!

P.S. haven't been on this group in years

---
Roberto

Roberto wrote:
> Hello,
>
> We just started looking at the greet_pause feature. Right now,
> greet_pause will return a 554 error code. Is there a way (without
> modifying the source code) to change this to 454 so that the remote
> server will queue the message and retry later?

If the client system is misconfigured and ignoring your greeting delay
why would you invite it back later? It will just fail again. If they
correct the problem it will be accepted on the next try. At least with
the 554 error the sender gets notified right away rather than hundreds
of retries and days later, and the admin has an opportunity to correct
the problem quickly. I'm puzzled as to what problem you're trying to solve.

dp

In comp.mail.sendmail Roberto <rullfig@uic.edu>:
> Hello,

> We just started looking at the greet_pause feature. Right now,
> greet_pause will return a 554 error code. Is there a way (without
> modifying the source code) to change this to 454 so that the remote
> server will queue the message and retry later?

Smells like a smtp protocol violation, likely ratware. Why would
you hand out a temporary failure?

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 359: YOU HAVE AN I/O ERROR -> Incompetent
Operator error

It would seem better for the remote server to queue up messages
instead of rejecting them immediately so that legit messages do not
need to be resent - they will just arrive later than normal. The
majority of users are totally confused when they receive a bounce
back.

On Jan 27, 5:19 am, Michael Heiming <michael+USE...@www.heiming.de>
wrote:
> In comp.mail.sendmail Roberto <rull...@uic.edu>:
>
> > Hello,
> > We just started looking at the greet_pause feature. Right now,
> > greet_pause will return a 554 error code. Is there a way (without
> > modifying the source code) to change this to 454 so that the remote
> > server will queue the message and retry later?Smells like a smtp protocol violation, likely ratware. Why would
> you hand out a temporary failure?
>
> --
> Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
> mail: echo zvpu...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
> #bofh excuse 359: YOU HAVE AN I/O ERROR -> Incompetent
> Operator error

In comp.mail.sendmail Roberto <rullfig@uic.edu>:
> On Jan 27, 5:19 am, Michael Heiming <michael+USE...@www.heiming.de>
>> In comp.mail.sendmail Roberto <rull...@uic.edu>:

>> > Hello,
>> > We just started looking at the greet_pause feature. Right now,
>> > greet_pause will return a 554 error code. Is there a way (without
>> > modifying the source code) to change this to 454 so that the remote
>> > server will queue the message and retry later?

>> Smells like a smtp protocol violation, likely ratware. Why
>> would you hand out a temporary failure?

> It would seem better for the remote server to queue up messages
> instead of rejecting them immediately so that legit messages do not
> need to be resent - they will just arrive later than normal. The
> majority of users are totally confused when they receive a bounce
> back.

If the remote server is trying to send before greeting has
happened it is a smtp protocol violation, which is likely the
reason for the 554 error sendmail hands out. The remote server is
miss configured or its smtp implementation completely broken.

What would a temporary error change? It would get the same on the
next try again and again, since it will misbehave again.

It is not a sendmail problem, but the problem of the sending
server which needs to be fixed. Unsure if you could except some
hosts from greet_pause with sendmail's implementation of it,
though why would you want to fix a problem that isn't yours?

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 81: Please excuse me, I have to circuit an AC
line through my head to get this database working.

>
> What would a temporary error change? It would get the same on the
> next try again and again, since it will misbehave again.
>

With a permanent failure the sending user immediately gets a return
message (not good). Communication with the end user should normally be
minimized. With a temp failure, the message is stored in the user's
smtp server queue where the administrator has to deal with it. With a
temporary failure the user does not need to resend the message after
the problem has been fixed by the administrator - in fact the user
need not be aware that there ever was a problem. To be on the safe
side we always try to return a temporary failure when possible. We
want our smtp configuration to have as little effect as possible on
legit senders. After analysis of incoming connections in this
particular case, it looks like returning a 554 code is having little
if any impact on legit senders so we should be fine.

Roberto Ullfig wrote:

> With a permanent failure the sending user immediately gets a return
> message (not good). Communication with the end user should normally be

Which MTA generates a permanent error if the connection is rejected
with 5yz?

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

I thought all codes beginning with 5 were returned to sender. Not the
case then? Which codes are returned to sender then? Can you point me
to some documentation on error codes? Thanks.

On Jan 29, 11:43 am, Claus Aßmann <ca+sendmail(-no-copies-
please)@mine.informatik.uni-kiel.de> wrote:
> Roberto Ullfig wrote:
> > With a permanent failure the sending user immediately gets a return
> > message (not good). Communication with the end user should normally beWhich MTA generates a permanent error if the connection is rejected
> with 5yz?
>
> --
> Note: please read the netiquette before posting. I will almost never
> reply to top-postings which include a full copy of the previous
> article(s) at the end because it's annoying, shows that the poster
> is too lazy to trim his article, and it's wasting the time of all readers.