Yes, we are in exactly the same situation. Our mailserver receives a lot of mail for various domains, and forwards to various users with xtra addresses. We are getting the exact same error – deferred etc

What I'm seeing is rather interesting, all my mail forwarded to xtra get accepted by mx1.tnz.mail.yahoo.com. Around 75% of the mail forwarded to mx2.tnz.mail.yahoo.com gets the "Deferred: 451 VS2-MF Excessive unknown recipients" -- ------------------------------------------------------------------------ Jean-Francois Pirus Senior Software Engineer Phone (+64-9) 358 2081 Clearfield Software Ltd Fax (+64-9) 358 2083 4th Floor 8-10 Whitaker Place Mob (+64-21) 640 779 P O Box 3901 Auckland, New Zealand ------------------------------------------------------------------------

mx1.tnz.mail.yahoo.com and mx2.tnz.mail.yahoo.com have the same ip address (currently anyway).

Any sane reason why you'd want to do that?

There are places which assume that you're a fly-by-nighter if you don't have "a stable mail platform", and having a secondary MX is seen as proof of that. Stupid I know... -Martin

Nathan Ward wrote:

Most fly-by-nighters tend to have 3 or even 4 MX records, with little purpose.

Yeah, mostly because naive advice is often given (usually by consultants that don't know any better) that, "you need a backup MX". Never mind that the backup MX isn't going to do anything that any semi-sane sender's MTA isn't going to do. Never mind that the only people with non-semi-sane MTAs are sending spam and malware. Or that the backup MX may have configuration differences which can lead to interesting (read: nasty) surprises. I figured out mumbleteen years ago, as rata.vuw.ac.nz's mail queue filled its disk partition *again* with umpteen copies of all the mail coming through the Novell mailing list (one of the highest traffic mailing lists back then) that wasn't going to be delivered that weekend because something had broken at a downstream site, that dumb secondary MXs are a very bad idea. I've always advised that if a secondary MX host isn't going to do anything useful with incoming mail other than re-queue it for delivery, then just don't bother. -- don

Blair Harrison wrote:

On 8/29/07, Don Stokes wrote:

...

I've always advised that if a secondary MX host isn't going to do anything useful with incoming mail other than re-queue it for delivery, then just don't bother.

-- don

I'd have to wholeheartedly agree with that. Back when I did run a secondary, it had to do even more strict spam filtering than the primary mail server, as we'd often see spammers sending mail to the secondary mail server only, so they obviously think this is a great attack vector. Usually mail coming in from a secondary wouldn't be scrutinised anywhere near as much as mail coming from an external mail source.

And I'd have to agree to disagree. :) At least, I agree in principle, but we have a useful case for having one. We use a single 2MX for all our clients. It allows us to notice quickly when a client is having mail issues at their site and thus be proactive in fixing them, and it also allows us to dequeue often urgent email after service restoration rather than wait for the MTA's normal retry interval. It's gotten us many a "thank you for the excellent service" from our generally pretty happy client base. Anyway, not that I am pushing 2MXes as a good idea, just saying that there are some good cases for having them in some situations. Cheers, Greig McGill

On 8/31/07, Joe Abley wrote:

[A] --------- [B] \ / X / X / \ / [C]

[A], [B] and [C] are different networks on the Internet. I have a priority-0 MX installed at [A], and another one at [B]. The MX at [A] has a lower number in its RDATA than the one at [B] (i.e. the one at [B] is the backup).

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

I'm just curious what reasons, and they may be myriad, explain why SMTP will route around the damage using the MX priority, but TCP/IP won't? Ie, I can send mail where I can't send a packet?

Joe

Hamish. -- http://del.icio.us/Hamish.MacEwan http://urltea.com/3jm?GoogleSharedItems

On 9/1/07, Hamish MacEwan wrote:

On 8/31/07, Joe Abley wrote:

...

[A] --------- [B] \ / X / X / \ / [C]

[A], [B] and [C] are different networks on the Internet. I have a priority-0 MX installed at [A], and another one at [B]. The MX at [A] has a lower number in its RDATA than the one at [B] (i.e. the one at [B] is the backup).

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

I'm just curious what reasons, and they may be myriad, explain why SMTP will route around the damage using the MX priority, but TCP/IP won't? Ie, I can send mail where I can't send a packet?

...

Joe

Hamish. --

Well B and A might be branch mail servers for a company and C is another company trying to mail them. Normally B and A have their own Internet connection but one of them goes down. C can still send to the other one and then the mail can get through to the other one as they have their own private company network as well as the public Internet. Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz

On Sep 01, 2007 20:35:23, Hamish MacEwan wrote:

On 8/31/07, Joe Abley wrote:

...

[A] --------- [B] \ / X / X / \ / [C]

[A], [B] and [C] are different networks on the Internet. I have a priority-0 MX installed at [A], and another one at [B]. The MX at [A] has a lower number in its RDATA than the one at [B] (i.e. the one at [B] is the backup).

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

I'm just curious what reasons, and they may be myriad, explain why SMTP will route around the damage using the MX priority, but TCP/IP won't? Ie, I can send mail where I can't send a packet?

Ah, I believe Joe was talking about the case where the MX servers are *different* servers, rather than the case (as with Xtra) where the same server is specified in multiple MX records. Jasper

On 9/1/07, Hamish MacEwan wrote:

I'm just curious what reasons, and they may be myriad, explain why SMTP will route around the damage using the MX priority, but TCP/IP won't? Ie, I can send mail where I can't send a packet?

Thanks for all the feedback, and I even found my own example, right here. I've been connected with ADSL and Wi-Fi to different ISPs and when either is down, there is no re-routing, but the two servers can still see each other across the LAN, so a secondary MX pointing to the other of the external IPs is useful, whether it points to, effectively, different machines or not (incoming port mapping). Hamish. -- http://del.icio.us/Hamish.MacEwan http://urltea.com/3jm?GoogleSharedItems

-----Original Message----- From: John S Russell [mailto:jsr(a)jsr.com] Sent: Monday, 3 September 2007 11:09 a.m. To: Hamish MacEwan Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Continued problems with xtra email

[...]

But the other MX on (B) is still reachable from (C) despite any or all of these possible reasons because it's on a completely different network and probably (if Joe's being sensible - and he always is[1]) one that's been chosen specifcally to be as diverse as possible from (A).

This is a pretty common setup for services like MX's, DNS servers, and other stuff that you'd like to have reachable more often than not, where support for multiple servers is built into the protocol itself.

JSR

Operational content, network architecture, ASCII art, beer. What more could one want from a thread? - Donald Neal Donald Neal | "Early rising is the burden of Alcatel-Lucent | the proletariat and the Support Engineer | affectation of millionaires." Technology Operations \ - Simon Templar HTC, Caro Street, Hamilton \ This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

On Mon, 3 Sep 2007, Bojan Zdrnja wrote:

That's all fine and nice. What I'm saying is that the MTA in [B] should have almost the same configuration as the one in [A]. It should certainly be able to reject e-mails for non existent users during the SMTP session otherwise the MTA in [B] can be a source of never ending NDRs.

Unless it decides to eat them instead, use them for classifying potential spam sources, or any one of the other myriad things it might decide to do. But hey, it's still a valid MX. --David

On Mon, 3 Sep 2007, Bojan Zdrnja wrote:

If you eat them, you run the risk of a legitimate user sending e-mail to a mistyped address and never receiving an NDR (sure, there are ways and logic around this but let's not go into those details)

Because so many legit users know what the bounces mean. 90% of the ones I see these days aren't very readable, and come from that nasty MAILER-DAEMON thing. Ooo, is that a virus?

On 8/31/07, Joe Abley wrote:

On 29-Aug-2007, at 0431, Blair Harrison wrote:

...

On 8/29/07, Don Stokes wrote:

...

I've always advised that if a secondary MX host isn't going to do anything useful with incoming mail other than re-queue it for delivery, then just don't bother.

I'd have to wholeheartedly agree with that.

[A] --------- [B] \ / X / X / \ / [C]

[A], [B] and [C] are different networks on the Internet. I have a priority-0 MX installed at [A], and another one at [B]. The MX at [A] has a lower number in its RDATA than the one at [B] (i.e. the one at [B] is the backup).

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

Please tell us that both [A] and [B] know all your users and domains (in other words: they reject e-mails for non existent users during the SMTP session). If not, I would say that [B] causes more problems for the world than it helps you because it probably generates zillion bounces per day ... Bojan

On 9/3/07, Joe Abley wrote:

On 2-Sep-2007, at 1546, Bojan Zdrnja wrote:

...

Please tell us that both [A] and [B] know all your users and domains (in other words: they reject e-mails for non existent users during the SMTP session).

[A] and [B] are networks, not mail servers.

Networks? So what do they have to do with MX records and multiple servers then? If your MTA in [A] is contactable through [B]'s network then you are fine with having just one MTA. Or I'm missing something ...

...

If not, I would say that [B] causes more problems for the world than it helps you because it probably generates zillion bounces per day ...

I suspect the world has greater things to worry about than how I manage the servers which handle my own mail.

Of course .. unless a spammer decides to do a dictionary attack on your domain and sends 100 million e-mails (of which all are to non existent user but that one going to you) and then your server send 100 million - 1 NDRs back. I see absolutely no reason why one would have multiple MX servers today at different networks. Multiple MTAs of course (preferably load balanced) but multiple MX servers - I see no real benefit. Add to that the fact that 90% of spammers hit MX servers with higher number *first* thinking that they won't have any spam filtering (and in most cases they are correct). Cheers, Bojan Bojan

On 9/3/07, Joe Abley wrote:

On 2-Sep-2007, at 1822, Bojan Zdrnja wrote:

...

On 9/3/07, Joe Abley wrote:

...

On 2-Sep-2007, at 1546, Bojan Zdrnja wrote:

...

Please tell us that both [A] and [B] know all your users and domains (in other words: they reject e-mails for non existent users during the SMTP session).

[A] and [B] are networks, not mail servers.

Networks? So what do they have to do with MX records and multiple servers then?

If you read the message you replied to and take note of what was actually written, as well as what you assumed was written, all will be revealed.

You still didn't answer then my original question. Let me paste that again to remind you (and what you said): In the original post you said:

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

So there is an MTA in both networks [A] and [B]. Then I said:

Please tell us that both [A] and [B] know all your users and domains (in other words: they reject e-mails for non existent users during the SMTP session).

And you said:

[A] and [B] are networks, not mail servers.

Sure, they are networks, but they both have MTAs. If your MTA in network [A] is your primary (and let's hope it's properly configured to reject e-mails for non existent users immediately) and the one in [B] has no idea about your users but knows that it has to accept everything for [A]'s domain then you have a problem I mentioned before. The benefit of having [B] as you described it is *only* if the network between [A] and [B] is private (otherwise it should be routable so [C] should be able to get to [A] over [B]). If this is the case, you can still have both of them as 1 MX record so you try to split the load between them. As I said, if MTA in [B] is secondary, you'll almost certainly see *higher* spam load on it than on [A]. Bojan

On 9/3/07, David Robb wrote:

On Mon, 3 Sep 2007, Bojan Zdrnja wrote:

...

Sure, they are networks, but they both have MTAs. If your MTA in network [A] is your primary (and let's hope it's properly configured to reject e-mails for non existent users immediately) and the one in [B] has no idea about your users but knows that it has to accept everything for [A]'s domain then you have a problem I mentioned before.

Since you're the one who added this extra aspect into the mix, and Joe's rightly pointed out that perhaps people should care about things other than how he runs his mail servers, you're making an awful lot of assumptions and accusations.

Lol - I'm not accusing anyone ... What I said:

Please tell us that both [A] and [B] know all your users and domains (in other words: they reject e-mails for non existent users during the SMTP session).

And Joe said:

[A] and [B] are networks, not mail servers.

I just wanted to point out that mistake number 1 people do (and that's all I wrote in my first post - go back and check) is that they just configure the MTA at [B] to be a secondary MX and then that results in loads of NDRs.

...

The benefit of having [B] as you described it is *only* if the network between [A] and [B] is private (otherwise it should be routable so [C] should be able to get to [A] over [B]).

Unless there are network issues, routing policies etc preventing this. Which is well, most of the point of backup MXs.

Fair enough. For most organizations though, if they have network issues with their main link they can afford to wait couple of hours for e-mails ...

...

If this is the case, you can still have both of them as 1 MX record so you try to split the load between them. As I said, if MTA in [B] is secondary, you'll almost certainly see *higher* spam load on it than on [A].

So?

No problem if you design everything correctly. Bojan

On 9/3/07, John S Russell wrote:

I'm not sure why you're bringing this up. Everyone else is talking about basic low-level connectivity - they ability for a mail server on network (C) of the diagram to deliver mail to and MAX on (B) if (A) is unreachable, or vice versa.

You're the only one who's brought up higher-level aspects of mail

Makes me feel special ;-)

processing and handling at this point. We're all talking about getting mail delivered to a valid MX, and you're the only one talking about what happens if the MX config is screwed up.

Sure, if Joe has his MX on network (A) configured correctly, and his MX on network (B) configured to do Stupid Shit, then (B) will surely do Stupid Shit. I don't see why you'd think this would be so.

Ok, this is the last post, I promise. I completely agree. If the MTA in [B] is configured to do Stupid Shit, it will do it - no argument about this. My main point was that I've seen that Stupid Shit being done in 99% of cases, while only 1% had MTAs properly configured (and I'm sure that Joe's server is properly configured, at least it is now ;-). If you take a look at some big e-mail providers you will see that they don't bother with low priority MX records - check hotmail.com, check yahoo.com (they don't even do it for their own domain). Google does this and I bet they have some *very* smart logic behind it. I'll go back sorting out my own e-mail now ;-) Bojan

On 2-Sep-2007, at 1908, Bojan Zdrnja wrote:

In the original post you said:

...

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

So there is an MTA in both networks [A] and [B].

Then I said:

...

Please tell us that both [A] and [B] know all your users and domains (in other words: they reject e-mails for non existent users during the SMTP session).

And you said:

...

[A] and [B] are networks, not mail servers.

Ah, but I also said:

...

I suspect the world has greater things to worry about than how I manage the servers which handle my own mail.

I realise you really want to talk about this, but really, I'm not interested. No doubt you will draw conclusions about this, but you may find that the world will thank you for keeping them to yourself. Joe

That sounds not unlike greylisting. Are you (erroneously) dropping mail when you get that response? On 4/10/2007, at 12:45 PM, Barry Murphy wrote:

Anyone had a fix or know a direct contact for someone at xtra to discuss email issues?

root(a)sophia:/home/icepick# telnet mx1.tnz.mail.yahoo.com 25 Trying 124.108.96.67... Connected to mx1.tnz.mail.yahoo.com. Escape character is '^]'. 421 Message from (60.234.68.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html Connection closed by foreign host. root(a)sophia:/home/icepick#

1 in every 5-10 attempts go through.

When mails do finally go through they are getting lost or added to spam folder, I cant find my mail server listed on any blacklists at all so can only suspect that yahoo has some local blacklist? Obviously this is a concern as clients aren't receiving invoices thus getting suspended after 3rd warning, then calling up to say they haven't received any info from us. I've tried sending from different email domains but problem persists, I'd suggest they've perhaps blocked my MX?

Xtra business complex faults suggest I can fill out a form which gets submitted to yahoo team, who will then send me another form to get my domain whitelisted, but they suggest I will have to do this for all 2000 domains on this one specific host.

Yahoo have some fairly draconian connection limits which don't work well if you're sending a lot of legitimate mail to them. We've had some success with customers using the form at http://help.yahoo.com/l/us/yahoo/mail/postmaster/defer.html and making it clear that they are an ISP and thus have a need to send a lot of valid mail to yahoo. Ask nicely enough and they will whitelist your mail server (not the domains), which doesn't remove the limits, but it does increase them significantly. Scott. On Thu, Oct 04, 2007 at 12:45:53PM +1300, Barry Murphy wrote:

Anyone had a fix or know a direct contact for someone at xtra to discuss email issues?

root(a)sophia:/home/icepick# telnet mx1.tnz.mail.yahoo.com 25 Trying 124.108.96.67... Connected to mx1.tnz.mail.yahoo.com. Escape character is '^]'. 421 Message from (60.234.68.30) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html Connection closed by foreign host. root(a)sophia:/home/icepick#

1 in every 5-10 attempts go through.

When mails do finally go through they are getting lost or added to spam folder, I cant find my mail server listed on any blacklists at all so can only suspect that yahoo has some local blacklist? Obviously this is a concern as clients aren't receiving invoices thus getting suspended after 3rd warning, then calling up to say they haven't received any info from us. I've tried sending from different email domains but problem persists, I'd suggest they've perhaps blocked my MX?

Xtra business complex faults suggest I can fill out a form which gets submitted to yahoo team, who will then send me another form to get my domain whitelisted, but they suggest I will have to do this for all 2000 domains on this one specific host.

Cheers Barry

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

No - normally you'd just run one MX.. this maybe because they want mail servers to retry the second mx.. (although the second mx is the same MX) Weird! -----Original Message----- From: Jean-Francois Pirus [mailto:jfp(a)clearfield.com] Sent: Wednesday, August 29, 2007 4:41 PM Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Continued problems with xtra email I have also just noticed that mx1.tnz.mail.yahoo.com and mx2.tnz.mail.yahoo.com have the same ip address (currently anyway). Any sane reason why you'd want to do that? dig xtra.co.nz mx ; <<>> DiG 9.2.5 <<>> xtra.co.nz mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28918 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;xtra.co.nz. IN MX ;; ANSWER SECTION: xtra.co.nz. 157 IN MX 10 mx1.tnz.mail.yahoo.com. xtra.co.nz. 157 IN MX 20 mx2.tnz.mail.yahoo.com. ;; AUTHORITY SECTION: xtra.co.nz. 12331 IN NS alien.xtra.co.nz. xtra.co.nz. 12331 IN NS terminator.xtra.co.nz. ;; ADDITIONAL SECTION: mx1.tnz.mail.yahoo.com. 157 IN A 124.108.96.67 mx2.tnz.mail.yahoo.com. 1309 IN A 124.108.96.67 -- ------------------------------------------------------------------------ Jean-Francois Pirus Senior Software Engineer Phone (+64-9) 358 2081 Clearfield Software Ltd Fax (+64-9) 358 2083 4th Floor 8-10 Whitaker Place Mob (+64-21) 640 779 P O Box 3901 Auckland, New Zealand ------------------------------------------------------------------------ _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

We are also doing the same. Unfortunately xtra loose out.. -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Wednesday, August 29, 2007 4:43 PM To: Michael J. Densem Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Continued problems with xtra email Same problem from a week ago, seeing as it's not fixed we're now referring clients to new ADSL providers and setting them up with pop accounts rather than forwarders. Many of them knew of the problems with xtra but thought they were fine because they could access pop3 and webmail however were un aware of the other issues regarding forwarding of domain based email, mail going abroad and queuing of email causing delays. Most are more than happy to move vendors after hearing this, previously they wouldn't because they thought this big corporation Telecom was there to offer them a good service. Regards Barry P.s. All communication in this email is my own opinion blah blah

Can anyone help?

Since Xtra changed over its email service to Yahoo! I have had problems.

I have a server (outside of the Xtra network) that handles email for around 50 domains.

Many of these are collection points that forward to client recipients with @xtra.co.nz addresses.

Due to the large volume of email traffic sending to the xtra.co.nz domain, the Yahoo servers are now blocking/grey-listing my server.

I have filled out the forms on the Yahoo website and have spoken to Xtra. However, I have had no response from Yahoo and Xtra doesn't seem to understand or appreciate the issue.

Is anyone else in a similar situation? Had similar issues?

Does anyone know a solution?

The response from the Yahoo servers is '451 Message temporarily deferred' (meaning Yahoo first denies the initial attempt and waits for a re-try).

However, none of the re-tries is accepted and the message eventually expires.

Any suggestions would be appreciated.

Cheers,

Mike Densem

mike(a)massive.co.nz

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog