try server sends mail with invalid email address



Release Engineering
4 years ago
a year ago


(Reporter: vlad, Unassigned)


Firefox Tracking Flags

(Not tracked)


(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 with -e nor 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 either bouncing or dropping it on the floor?
Hmm.  Nothing in my 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 as a relay.
So we tracked this down to being caused by the address used for the sender: "". The domain no longer exists, so some mail servers are rejecting the mail.

Two options going forward:
- change the sender address ("" ?)
- add a dns entry for

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 should work fine.  With release+trybuilds, you'll get some backscatter.  Probably the best will be
Can we just make a cname for -> That would make this work, and noone will need to change filters.  Filtering for "" 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 resolve at all - bug 604688.  We could easily send from, 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 (  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 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 or 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
Last Resolved: 4 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 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

Hmm, doesn't seem to have worked, or maybe didn't get propagated to yet? isn't providing an answer, just sending back itself as authoritative..

; <<>> DiG 9.8.1-P1 <<>>
; (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

;             IN      A

;; AUTHORITY SECTION:            60      IN      SOA 2014011400 180 180 1209600 60

;; Query time: 75 msec
;; 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 as a full email domain, with at least trybuilds@ defined?
Resolution: FIXED → ---

Comment 15

4 years ago
Created an MX

limed@kaylee:~$ dig @ mx  +short

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?)

Comment 17

4 years ago
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
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED


a year ago
Component: Tools → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.