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

On Fri, 21 Dec 2007, Phil Pennock wrote:
> On 2007-12-21 at 23:47 +0100, Leonardo Boselli wrote:
> > Try later ... after 24 hours ????
> No, but from the same IP is appreciated.
actually at least the last 3 tries came from the same server (althought it
has 4 addresses)
> I dislike greylisting but use it, with the daemon from Debian, munged
> 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.

NO. all the email from my department is sent throught smarthosts, or at
least from a server with its own fixed IP that are on 24/24 (except in
case of maintenance).
> 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.
> But if you bounce around, never staying in one place for long, only
> trying once, then you start to look like a spammer.
I (or better my server) does not bounce around: just has a rule that if
the two main servers (that offer pop3 and imap service to users,
an that act as smarthosts for local users) cannot
send directly within 5 minutes, to save CPU cycles, they pass
the message to one of the backup servers (the ones with higher mx) that in
turn tries next retries, using if failing one with a 4xx message (or
being unable to connect), a different routing and of course a different
ip. So in the worst case a message could be sent with 5 different IP from
three different networks. But these are always from at most two servers !

> 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*

Ok but what if my MTA has 4 address on 4 subnets from 3 different
providers an use each one in turn ? (none of provider warrant a 100% up
time, but just a nominal 98.5).