Closed Bug 958838 Opened 11 years ago Closed 11 years ago

try server sends mail with invalid email address

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86_64
Windows 8
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: vlad, Unassigned)

Details

(component might be wrong) I've tried using the -e option for tryserver builds, but I still don't get any emails. I was successfully getting all emails before the default changed. Any ideas if this is working? (Is there a good way to figure out what your tryserver job was, other than scrolling back on tbpl?)
Indeed, neither https://tbpl.mozilla.org/?tree=Try&rev=3152231fa396 with -e nor https://tbpl.mozilla.org/?tree=Try&rev=e3cd9555c7bc with -f have sent me anything other than the "thanks for your push" mail. Of course, your observed problem, not knowing where to find your push, must be something else, because -e, -f, and the default do all send the initial "Thank you for your try submission. It's the best!" email with the link to tbpl for the push. Did you set up a filter back when the default was massive emails, or did you set up a filter for tbplbot spam which also filters that email? Or is pobox.com either bouncing or dropping it on the floor?
Hmm. Nothing in my pobox.com held spam, and nothing in gmail (pobox forwards to gmail). I was getting tryserver mail fine, but the last push where I got mail was 6/13/13. (I just assumed it went away, and I wasn't using the tryserver much for a while.. so it could have broken at any point along the way there.) I suppose it's possible that pobox is bouncing it, but it usually doesn't bounce any mail (just holds it). Any way to check our mail logs?
All this mail should be going through mail.build.mozilla.org as a relay.
So we tracked this down to being caused by the address used for the sender: "tryserver@build.mozilla.org". The domain build.mozilla.org no longer exists, so some mail servers are rejecting the mail. Two options going forward: - change the sender address ("release+trybuilds@mozilla.com" ?) - add a dns entry for build.mozilla.org I don't have a strong preference either way. RelOps may want to chime in here.
Flags: needinfo?(dustin)
Summary: try server doesn't seem to send email addresses with -e → try server sends mail with invalid email address
Any address @mozilla.com should work fine. With release+trybuilds, you'll get some backscatter. Probably the best will be nobody@mozilla.org.
Can we just make a cname for build.mozilla.org -> tbpl.mozilla.org? That would make this work, and noone will need to change filters. Filtering for "nobody@mozilla.org" would be unfortunate.
We can't make a CNAME for it because it has subdomains. In fact, we put a great deal of effort into not having build.mozilla.org resolve at all - bug 604688. We could easily send from trybuilds@mozilla.org, though, if that would help filtering.
Flags: needinfo?(dustin)
Ok, if no CNAME, just an A record, pointing to the IP for tbpl.m.o (generic.zlb.phx.mozilla.net)? It doesn't have to actually go anywhere "real", it just needs to be valid. trybuilds@m.o would fix my problem, but requires everyone to update their filters. Just making build.m.o have an IP would solve this issue. In bug 604688 Aki seems to be referring to the confusion between services running on build.mozilla.org vs the subdomain; if we just gave it an A then there still wouldn't be any services running on it, so there's no confusion. (In fact, if it just had an address, everyone could continue to be blissfully unaware that it has an address, except that mail servers will start accepting mail from it :)
Any reason why we can't do one of the two solutions today? Seems like either one would be a simple one-line change that could be reviewed by whoever's sitting next to whoever does the change. I have a slight (maybe slightly strong) preference for adding an A record because it is the least disruptive change, but ultimately it doesn't matter.
Why do you suggest that the A record point to tbpl.m.o -- why not alt2.gmail-smtp-in.l.google.com or emvm-gh1-uea09.nsa.gov or any of 4 billion other IPs? It smells awful to me that we're sending mail from an undeliverable address, and I hate to perpetuate things with a bad code-smell which violate the principle of least surprise. Witness the surprise that DNS configuration for a domain unrelated to email has affected email. It's impossible to say that such a thing wouldn't happen again. I wasn't aware people were filtering on this address, though. I guess it comes down to a bad smell or a few papercuts. I held my nose and added an A record pointing to one of the MX's for mozilla.org.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Oh, incidentally, when you push to try, you get a tbpl link right back .. no need to wait for the email :)
Awesome, thanks! I picked that host because that's what tbpl was pointing to :) Generic mozilla.org works just as well though! And yup, I do get a link as soon as I push.. and then that link disappears in my shell history, or sticks around in the shell of my desktop when I'm on my laptop etc :)
(In reply to Dustin J. Mitchell [:dustin] (I ignore NEEDINFO) from comment #10) > I held my nose and added an A > record pointing to one of the MX's for mozilla.org. Hmm, doesn't seem to have worked, or maybe didn't get propagated to ns.mozilla.org yet? ns.mozilla.org isn't providing an answer, just sending back itself as authoritative.. ; <<>> DiG 9.8.1-P1 <<>> @ns.mozilla.org build.mozilla.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61433 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;build.mozilla.org. IN A ;; AUTHORITY SECTION: mozilla.org. 60 IN SOA ns.mozilla.org. sysadmins.mozilla.org. 2014011400 180 180 1209600 60 ;; Query time: 75 msec ;; SERVER: 63.245.215.5#53(63.245.215.5) ;; WHEN: Wed Jan 15 03:10:26 2014 ;; MSG SIZE rcvd: 84
Hah, I made the record internal only, and of course it worked while connected to VPN. I fixed that up now, so once it propagates (a few minutes) this should work again. Ed, should we use an MX instead? And should we set up build.mozilla.org as a full email domain, with at least trybuilds@ defined?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created an MX limed@kaylee:~$ dig @8.8.8.8 build.mozilla.org mx +short 10 mx2.corp.phx1.mozilla.com. 10 mx1.corp.phx1.mozilla.com. This should now forward to our MX servers and forward them on to another shared email account. Can we consider this done?
Works now! I just got a whole slew of email. Thanks all :) (Letting one of you guys resolve it, in case there's anything more to be done?)
Just cleanup of the A record, it doesn't need the A record just the MX. But the cleanup is done so I'm resolving this
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.