Re: [exim] bouncing message, improper configuration of serve…

Góra strony
Delete this message
Reply to this message
Autor: Phil Pennock
Data:  
Dla: Leonardo Boselli
CC: exim-users
Temat: Re: [exim] bouncing message, improper configuration of server.
On 2007-12-21 at 23:47 +0100, Leonardo Boselli wrote:
> Try later ... after 24 hours ????


No, but from the same IP is appreciated.

I dislike greylisting but use it, with the daemon from Debian, munged
about a bit to work on FreeBSD. The retry time is 10 minutes: retrying
just 10 minutes after the original attempt would have worked.

Looks like you're sending direct-to-MX from a portable machine which
changes IP addresses as it moves around, connecting from student
networks and then later a business DSL line. That's based on the IPs I
saw for you trying to send to me. If this is wrong, take a closer look
at your retry time settings.

So if you keep mail queued on a system which is not even able to connect
to the Internet for long periods and is only briefly on from various
locations, then yes you'll have difficulty sending to many places.

Reliable delivery involves reasonable attempts to retry on the part of
the sender. You could investigate using a permanently connected machine
as a smarthost which you relay through. You could have your laptop
attempt to connect directly and, if it fails to do so at first attempt,
deliver to the smarthost for retrying.

But if you bounce around, never staying in one place for long, only
trying once, then you start to look like a spammer. I regret that the
world is this way and that one IP address is not like another. I regret
that there are now multiple tiers of quality of IP address space and
that I end up supporting this by use of RBL whitelists which get to skip
past greylisting. I'm not too upset though, since a non-whitelisted IP
address can still get through, it's just that the first attempt takes a
few moments.

Email works better when fixed MTAs talk to fixed MTAs and client
machines talk to mailstores and fixed MTAs within their own
administrative domain.

Although it doesn't mandate use of stable IP addresses, it's worth
taking a look at BCP 134 (RFC 5068) on "Email Submission Operations:
Access and Accountability Requirements" to get a feel for the current
IETF thinking on how email architectures should work. Whether or not
the MTA on a laptop counts ... *shrugs*

> ---------- Forwarded message ----------
> Date: Fri, 21 Dec 2007 17:23:01 +0100
> From: Mail Delivery System <Mailer-Daemon@???>
> To: leo@???
> Subject: Warning: message 1J5JXM-00004y-74 delayed 24 hours
>
> This message was created automatically by mail delivery software.
> A message that you sent has not yet been delivered to one or more of its
> recipients after more than 24 hours on the queue on vettore.dicea.unifi.it.
>
> The message identifier is:     1J5JXM-00004y-74
> The date of the message is:    Thu, 20 Dec 2007 12:35:22 +0100 (CET)
> The subject of the message is: Re: [exim] secondary MX: allow only a set of users

>
> The address to which the message has not yet been delivered is:
>
>   exim-users@???
>     Delay reason: SMTP error from remote mailer after RCPT TO:<exim-users@???>:
>     host mx.spodhuis.org [193.202.115.177]: 451-81.119.23.246 is not yet authorised to deliver mail from
>     451 <leo@???> to <exim-users@???>.  Please try later.

>
> No action is required on your part. Delivery attempts will continue for
> some time, and this warning may be repeated at intervals if the message
> remains undelivered. Eventually the mail delivery software will give up,
> and when that happens, the message will be returned to you.