This looks promising. In answer to your question, forget the first part about direct smtp delivery (we have no intention to keep this long term this is just something we are playing with in our lab). Yes we want to have a small group of centralized SMTP servers and the main capability we are looking to gain here is _automated_ delivery failover temporarily so we can at least get mail flowing to problem destinations through another path while we sort out the reputation problems which can sometimes take alot of time to fully clean up. Usually we jump in to the affected server and will manually divert the problem destinations to elsewhere and work on the problem.
The pipe dream would be to have SMTP A,B,C for example and have a situation where lets some event happens where real spam gets sent from a compromised account and this affects reputation of SMTP A to where various destinations will not accept mail due to this. What we would like to do somehow is if SMTP A fails to deliver to all any/all MX records, before sending a NDR to the sender we would like to forward this message to SMTP B and continue down the line until the message can get delivered. Lets say we fail to deliver the message through all of our SMTP relays because the problem is on the receipients end where the recipients email server is down or their DNS is screwed up or something like that then at that point we have exhausted all our available options and it would be acceptable to send a NDR back to sender. If we could also somehow get notifications of this that could warn us like "message $x failed and is retrying on other relays" that would very useful as we could start working on the reputation problem hopefully as soon as the first (or first few) messages are failing. If the user didnt get an NDR until all SMTP servers failed to deliver then the customer isnt contacting us until its a complete failure at which point we definitely do want them to contact us, but if it went through an alternate relay we could ideally fix the issue and the end users mail is delivered (possibly delayed) but is never affected or aware of the issue. Hope this explanation makes sense and gives a better view of what we are trying to do. Thanks for all the input so far chris On Tue, Apr 7, 2015 at 12:00 PM, Jim Dunphy <[email protected]> wrote: > postfix has transport maps which would force delivery through another one > of your servers so that might be part of your solution. You also might be > able to do some manual requeuing and then restart the queues with a > different sendmail.cf file to a smart host after direct connection has > failed. For example, qtool.pl has been used for years to implement > various outgoing delivery queues such as 4, 8, 12, 24 hour for sendmail. > > Are you trying to get around short term or transient blocking from some > of your webserver's ip space when they get caught up in a large cidr block > - then route around that problem vs waiting it out with re-delivery? > > For on demand web servers, it might be easier to use smart relays in their > configurations and get the mail off the web servers first and then apply > the intelligence on those outgoing smart mail relays and its queuing...not > to mention you should gain additional ability to make fewer connections to > other mail servers in some instances and/or the ability to throttle your > outgoing traffic.Not to mention, its another place to do more intensive > outgoing filtering and additional checking. > > HTH, > > Jim > > On Tue, Apr 7, 2015 at 7:30 AM, chris <[email protected]> wrote: > >> Hello, >> >> I have a few linux webservers and which each send out SMTP directly . >> Currently, the webservers all relay the message directly to receipient and >> if it cant then it sends back a NDR to the sender advising the sender the >> message could not be delivered. >> >> I want to scale this out a bit and add 2 "backup" SMTP server but what I >> want to do is have the webservers try to deliver the message and also have >> both SMTP A and SMTP B as backup relays and I want it so that if the >> webserver cannot deliver the message directly then have it try SMTP A, this >> server would keep the connection to webserver open and attempt to relay >> right away and if it fails REJECT the message so the webserver will try the >> next server SMTP B etc etc. >> >> I am just wondering if anyone knows how to do this or something like it. >> As far as MTA I am familiar with exim,postfix,sendmail and not tied down to >> a specific one so whichever gives this functionality is fine. >> >> Basically the problem I am trying to solve is to have a little bit of >> SMTP HA sort of so that if lets say the webserver cant reach the >> receipients mail server due to some routing problem or lets say if the >> receipient mail server has some kind of firewall that was blocking certain >> ranges of IP's, then we just want the message to retry on some other SMTP >> relays which we can spread out on different networks as backups so we can >> hopefully just get the message delivered an alternate way to buy us time to >> look into why it couldnt be delivered the normal way. >> >> I am not really like looking for a commercial solution but rather to >> build the setup out of existing open source software. We are all command >> line ninjas so we dont need a point and click gui or any appliances :) >> >> If anyone has a setup like this I'd be curious to pick your brain and see >> what worked and didnt work for you. >> >> TIA >> chris >> >> _______________________________________________ >> mailop mailing list >> [email protected] >> http://chilli.nosignal.org/mailman/listinfo/mailop >> >> >
_______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop
