At 09:50 AM 3/17/2003 +0000, Giuliano Gavazzi wrote:
>2) although it mentions here human intervention, it is clear that in this
>case human intervention cannot change the order of MX, if you exclude
>talking to the DNS maintainer, and even this action might be precluded if
>the maintainer has got an address in the same domain. Contact telephone
>numbers are not necessarily available too.
I take this to mean allowing the _sender_ to physically resend his mail
later, after the admin at the other end has rectified whatever caused an MX
to be pointed at a host that's not answering SMTP requests.
>If, as Florian and I suggested, we repeat the request changing the
>parameter that caused the failure, that is changing the MX used in this
>case, we are within the standard. And before anyone says that retries
>should be at 30m intervals at least, let me repeat that the standard
>explicitly allows the SMTP client to be more flexible when it can
>determine the cause of failure (in this case: using a particular MX).
If you are determining a cause of failure, sure. However, if you happen to
be sending bulk mail of any sort (solicited, confirmed optin bulk mail,
even ...), trying to work around a 5xx block is likely to trigger one or
more alarms. RFC or not. I've seen this in my ~ 4..5 years of abuse desk
experience, and I've seen my colleagues at other ISP abuse desks feel the
same way.
>all, as Philip pointed out, this 554 might just mean that there is no SMTP
>service at the domain as a whole (not just the MX host). Clearly this last
>possibility indicates that the email address was incorrect and the user
>must be told immediately.
>If this means too much extra complication added to exim, let's forget
>about it, it is a rare occurrence after all.
Fine with me.
>May I assume that G.A.W. will say that I am taking these RFC paragraphs
>out of context?...
I can safely assume that. In fact, I think your interpretation is a bit
far fetched, myself .. :)
suresh
