account confirmation mail is sent using an invalid address

VERIFIED FIXED

Status

mozilla.org Graveyard
Server Operations
--
blocker
VERIFIED FIXED
12 years ago
3 years ago

People

(Reporter: Justin Mason, Assigned: mrz)

Tracking

Details

(URL)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

I tried to set up an addons.mozilla.org developer account, and didn't receive the confirmation mail.  After a few minutes, I took a look to see if it had been dropped or blocked, and found this in the syslog:


Aug 25 16:26:37 dogma postfix/smtpd[9175]: connect from webapp01.sj.mozilla.com[63.245.208.146]
Aug 25 16:26:37 dogma postfix/smtpd[9175]: setting up TLS connection from webapp01.sj.mozilla.com[63.245.208.146]
Aug 25 16:26:38 dogma postfix/smtpd[9175]: TLS connection established from webapp01.sj.mozilla.com[63.245.208.146]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Aug 25 16:26:38 dogma postfix/smtpd[9175]: NOQUEUE: reject: RCPT from webapp01.sj.mozilla.com[63.245.208.146]: 450 <apache@mrapp07.mozilla.org>: Sender address rejected: Domain not found; from=<apache@mrapp07.mozilla.org> to=<jm-firefox@jmason.org> proto=ESMTP helo=<mrapp07.mozilla.org>


In other words, my Postfix server refused the message, since it claimed
to come from a domain that doesn't exist -- mrapp07.mozilla.org .  Sure
enough, that host/domain doesn't resolve.

The webapp should send its mails using a resolveable domain in the source
addresses.

Reproducible: Always

Steps to Reproduce:
1. Create a new account at addons.mozilla.org
2. wait for account confirmation
3. examine message headers for 'mrapp07.mozilla.org' used in a HELO string or "from" header
(Reporter)

Comment 1

12 years ago
btw, the Postfix feature that does this is 'reject_unknown_sender_domain' -- but it's very common to refuse unresolveable sender addresses in most other MTAs and anti-spam software.
*** Bug 350153 has been marked as a duplicate of this bug. ***
Thanks for your investigation on this, it will help greatly. Looking through recent check-ins, I don't think this was an AMO code problem. CC'ing oremj for his advice.

Also, your AMO account has been activated.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

12 years ago
'Also, your AMO account has been activated.'

thanks ;)  FWIW, i turned off the 'reject_unknown_sender_domain' postfix feature anyway so that I could confirm the account.  but it's obviously something that should be fixed since there are definitely others seeing the issue...
Yes, it's pretty serious - all week various people have said they didn't get e-mail notification that their add-on was approved/denied. It is affecting all e-mails from AMO.
Oy, that explains a lot of our pain.  Seems like the MTA should be rewriting the domain here, so over to ops.
Assignee: nobody → server-ops
Severity: major → critical
Component: Administration → Server Operations
Product: addons.mozilla.org → mozilla.org
QA Contact: administration → justin
Version: unspecified → other
OS: Linux → All
Hardware: PC → All
(Assignee)

Updated

12 years ago
Assignee: server-ops → justdave
Nice of someone to assign this to me and not tell me about it being that it's critical and all (I've been working on projects and ignoring bugmail because I get too much to pay attention to it and still get anything else done).

I was on my way to bed when morgamic snagged me to ask if anything was being done with it, and I'm too tired to trust myself fixing it without breaking things, so assigning back to on-call.

mrapp01/02 were set up correctly because of the same thing happening to WFFD a while back.  I didn't know there were additional app servers since then.  I'm willing to bet you can fix this by copying the /etc/mail directory off of either mrapp01 or mrapp02 onto the rest of the app servers and restart sendmail on all of them.  We also need to make sure that instruction gets put somewhere (or that sendmail.cf into the cluster config channel on RHN) for future deployments.
Assignee: justdave → server-ops
Raising to blocker severity. On-call sysadmin, please see comment #7 for information.
Severity: critical → blocker
(Assignee)

Comment 9

12 years ago
I rsync'd over /etc/mail from mrapp01 to mrapp0[3-8] and restarted sendmail.  

Sorry Dave - hadn't realized it was marked as critical when I first saw it.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Assignee: server-ops → mrz
Created a test account and it is indeed working again. Thanks.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.