Re: Multiple SMTP gateways in one MX record
On Tue, Sep 29, 2015 at 09:13:48AM +0200, Zalezny Niezalezny wrote: > one of my team colleagues decided to configure multiple SMTP gateways for a > single domain. > > domain.com > > MX > 10 gate1-1.com(primary MX) > 10 gate1-2.com(second primary MX) > 30 gate2-1.com(backup MX) > 30 gate2-2.com(backup MX) > 60 gate3-1.com(backup MX) > 60 gate3-2.com(backup MX) > > domain.com - gate1 > domain2.com - gate2 > domain3.com - gate3 > > If SMTP server on one domain will not be available, then client will use > another one. This is fine, provided the backup MX hosts are properly configured to accept and relay the mail to the gate-1 primary MX hosts, *and* have working recipient validation (don't accept and then bounce mail for non-existent recipients). > I`m sceptic about this because my team has access only on to gate1 and in > case of problems (eventual bounce) it will be hard to analyse the problem. > Does it make sense ? The configuration is fine, if implemented correctly, otherwise remove the backup MX hosts, two primaries are typically enough, unless you're concerned about losing network connectivity for both for a prolonged span of time (and the backup MX hosts will queue mail long enough to ride out the outage). -- Viktor.
Multiple SMTP gateways in one MX record
Dear Colleagues, one of my team colleagues decided to configure multiple SMTP gateways for a single domain. domain.com MX 10 gate1-1.com 10 gate1-2.com 30 gate2-1.com 30 gate2-2.com 60 gate3-1.com 60 gate3-2.com Each SMTP gate belong to separate domain and its manage by separate team. domain.com - gate1 domain2.com - gate2 domain3.com - gate3 If SMTP server on one domain will not be available, then client will use another one. I`m sceptic about this because my team has access only on to gate1 and in case of problems (eventual bounce) it will be hard to analyse the problem. Does it make sense ? How to analyze eventual Postfix mail bounces in such a constelation ? p.s. I know that is not fully Postfix related question, but maybe somebody will be able to put some hint/opinion about it. Thanks in advance. Cheers Zalezny
Backup MX port
Hi, I have been trying to use a third-party backup provider to cover occasional outages (SiXwishlist). I set up an MX record as instructed but I get no emails sent on when my server recovers. I asked them to check what was happening and they told me my port was not open. It seems they were expecting postfix to be listening to port 4000. I asked for clarification and got a response that they would send emails on 587, 2525, 3000, and 4000, but that 25 was not recommended and "is blocked for 90% of service hosting providers". I thought that smtp/25 was the backbone of email systems. I use 587 internally for submission so I don't see why I would make it accessible to the outside world. Do I need to open another port? Have I got port 25 wrong all this time? Or do I need to get myself a proper backup provider? Thanks, Robert Sharp
Re: Backup MX port
Robert Sharp: > Hi, > > I have been trying to use a third-party backup provider to cover > occasional outages (SiXwishlist). I set up an MX record as instructed > but I get no emails sent on when my server recovers. I asked them to > check what was happening and they told me my port was not open. It seems > they were expecting postfix to be listening to port 4000. I asked for > clarification and got a response that they would send emails on 587, > 2525, 3000, and 4000, but that 25 was not recommended and "is blocked > for 90% of service hosting providers". > > I thought that smtp/25 was the backbone of email systems. I use 587 > internally for submission so I don't see why I would make it accessible > to the outside world. Do I need to open another port? Have I got port 25 > wrong all this time? Or do I need to get myself a proper backup provider? What you describe sounds more like a primary MX service to me where the typical customer is behind a port-25-blocking provider. A downside of not using port 25 for forwarding is that you now also need to maintain service on a different port, but there is no reason why it could not be done, if it is based on mutual agreement. Wietse
Re: Backup MX port
On 2015-09-29 05:13, Robert Sharp wrote: I have been trying to use a third-party backup provider to cover occasional outages (SiXwishlist). I set up an MX record as instructed but I get no emails sent on when my server recovers. I asked them to check what was happening and they told me my port was not open. It seems they were expecting postfix to be listening to port 4000. I asked for clarification and got a response that they would send emails on 587, 2525, 3000, and 4000, but that 25 was not recommended and "is blocked for 90% of service hosting providers". as wietse mentioned, it sounds like they are used to acting as the primary mx for customers whose providers block 25/tcp inbound. in those cases, they receive mail on 25/tcp on your behalf and then connect to your mail server on an alternate port (such as one of the above) that is not blocked by your provider. this can -- and does -- happen often enough that there is a market for this service. I thought that smtp/25 was the backbone of email systems. I use 587 internally for submission so I don't see why I would make it accessible to the outside world. Do I need to open another port? Have I got port 25 wrong all this time? Or do I need to get myself a proper backup provider? you're correct and you're doing things the right way, afaict. 25/tcp *is* the standard port for mta to mta delivery and 587/tcp *is* the standard port for mua to mta delivery. probably the easiest thing to do in your particular case is to make your mta available on one of these non-standard ports that they will attempt to deliver to -- in addition to, not instead of, 25/tcp. there are a few different ways to accomplish this but the simplest, in my opinion, would be to simply forward incoming connections to 2525/tcp from their mail servers to 25/tcp on your mail server. if you are using linux & iptables on your mail server, it's as easy as adding rules such as the following (substituting in the ip addresses/ranges of their outgoing mail servers, of course): iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2525 -s x.x.x.x/yy -j REDIRECT --to-port 25 hth, /chl
spf fail on ietf.org
https://dmarcian.com/spf-survey/ietf.org fail is p6 should be ip6 help me to solve it
Re: spf fail on ietf.org
The tech contact for the domain is listed as gdm...@gmail.com Might be worth dropping them an email On 29/09/2015 9:43 pm, Benny Pedersen wrote: > https://dmarcian.com/spf-survey/ietf.org > > fail is p6 should be ip6 > > help me to solve it signature.asc Description: OpenPGP digital signature
