On Thu, Nov 25, 2010 at 10:33:33AM +0100, Angelo Amoruso wrote:
> One situation is when having Postfix using as smarthost your ISP
> smtp server.
> Nowadays the smtp server DNS record is actually a round-robin dns
> name or set of aliases which points to a pool of smtp servers.
>
> Example:
>
> smtp.n3bula.com
>
> resolves to:
>
> 62.149.128.202, 62.149.128.203, 62.149.128.200, 62.149.128.201
>
> Happens often that one of more of the ISP server which the name
> resolves to is being listed in some RBL blacklist.
The only real solution to this problem, after complaining to the ISP,
is to change to a better ISP. There are hacks to work around their
ineptitude[1], but you're paying good money for your Internet
service. They are failing to deliver an essential part of it.
Small-time operators often benefit from cheap VPS services, wherefrom
you can deliver your own mail directly. NOT a good idea for senders
of bulk mail, but it might work well otherwise.
The email world is a terrible mess. If there's money involved, don't
think you can get by cheaply; outsource it. Thank the spammers for
this.
> And then you've a strange scenario: some emails get through and
> get delivered, some bounce remotely at destination 'cause the
> server blacklisting.
> Which, warning and error messages apart, gives some headache to
> users.
>
> What I'd to accomplish is checking if the smtp server I'm about to
> delegate the outgoing mail is blacklisted (using a defined list of
> rbl providers) if not, trying the next ip address (if any),
> otherwise wait and do it again.
And what happens if the ISP changes to some other sort of load
balancing? Your mail goes in to one of the MSAs, and then is passed
to a different host for outbound. Do they maintain a strict
correlation between the inbound and outbound hosts? Do they tell you,
or are you left to guess?
It's ugly. You're trying to make a proverbial silk purse out of a
sow's ear here. All that work, and your lousy ISP is at liberty to
break it any time, without warning to you.
> One very-raw-and-unelegant way - keeping the email inside the
> Postfix queue - would be having such detection process outside
> postfix on a special program, which would do the checks
> periodically and then update the main.cf configuration file
> accordingly.
The whole thing is ugly. But if you were to do that, I would suggest
scripting something to update your own internal DNS, and leave
Postfix / main.cf alone after this:
# no [hostname.bracketing] means look up MX
relayhost = outmx.site
And "dig outmx.site. mx" yields this:
outmx.site. IN 600 10 goodrelay.1.example.net.
outmx.site. IN 600 10 goodrelay.2.example.net.
...
> Hope my explaination (and my English ;-)) was clear enough;
> otherwise feel free to ask more details, I'd be pleased to provide
> more.
The explanation is clear. I would say, don't do this at all. Good
luck, you will need it if your ISP is that bad.
[1] Ineptitude is a strong word, and I don't mean to be that harsh.
Running a MTA/MSA for a wide range of users is a difficult job.
But indeed, widespread ineptitude is how things got to be this
bad in the first place. Your ISP needs to outsource if they are
unable to hire good postmasters.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
