350187 - account confirmation mail is sent using an invalid address

Status: VERIFIED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Justin Mason]

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 <[e-mail]>: Sender address rejected: Domain not found; from=<[e-mail]> to=<[e-mail]> 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

Comment 1

[Justin Mason]

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.

Comment 2

[Justin Scott [:fligtar]]

*** Bug 350153 has been marked as a duplicate of this bug. ***

Comment 3

[Justin Scott [:fligtar]]

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.

Comment 4

[Justin Mason]

'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...

Comment 5

[Justin Scott [:fligtar]]

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.

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Oy, that explains a lot of our pain.  Seems like the MTA should be rewriting the domain here, so over to ops.

Comment 7

[Dave Miller [: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.

Comment 8

[Reed Loden [:reed]]

Raising to blocker severity. On-call sysadmin, please see comment #7 for information.

Comment 9

[matthew zeier [:mrz]]

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.

Comment 10

[Justin Scott [:fligtar]]

Created a test account and it is indeed working again. Thanks.