Re: [Exim] Reaction to rude 554 greeting

Top Page
Delete this message
Reply to this message
Author: Drav Sloan
Date:  
To: Dean Brooks
CC: exim-users
New-Topics: For exim sake! Re: [Exim] Reaction to rude 554 greeting
Subject: Re: [Exim] Reaction to rude 554 greeting
Dean Brooks wrote:
> What does the author of Exim think about this option at this point?
> Last I saw, his comments were that this was a bad idea.


Agreed.

> So far, I only see a couple of people who are wanting this unusual
> treatment. Wouldn't this possibly be better left to those individuals
> making their own patch and redistributing among themselves than adding
> this sort of stuff to the main distribution?


Agreed also. At the end of the day, peoples lazy attitude to a remote
mailer giving a _permanant_ error, and 'automatically' going off and
trying seconday MXes is seen as abuse in my eyes, and is likely to
have you blacklisted.

The 'justifying' by snipping bits of RFC out of context doesn't
hold water for me. A 5xx serier error is a permanat error, full
stop. No if's no buts, not 'oh in this senario', NO. A 5xx should
cause a bounce, and it's up to the SENDING user to decide on the
action to take _manually_. Fudging exim to make it non-RFC, or be
totally ignorant of 5xx codes seems like a bad avenue to take;
because then all sorts of anti-RFC crap will end up in what Philip
has strived to be an RFC complient mailer.

> If we are going to start treating specific error codes differently,
> I'd much rather see some generic way of specifying a result code tied
> to a specific ACL. Even then, I don't know how useful that would be.


Or as you say, these people who feel the need to be lazy and ignore
RFC should pass their own exim patch about.

Purely because 'they dont want to deal with people phoning them'
as a reason to add this option sits really uncomfortably with me.

(That your !^"^!* job as a postmater, to deal with these EXACT
issues, fudging your mailserver so you dont have to 'do more work'
is just plain lazy and shirking your responibilities.

> Is there any precedent on this issue with Sendmail, Qmail or other
> mailers?


Not that I know of.

D.