firstname.lastname@example.org no longer working - Bitbucket using a fake/non-existing Envelope Sender address causes e-mail rejections
Please fix the e-mail address email@example.com - it currently does not exist.
Up until last month, the e-mail address firstname.lastname@example.org was working fine - your incoming mail server accepted DSNs for this address, for example, on this occasion (extract from our e-mail service provider's mail server log):
2013-10-15 19:26:43 1VW9KN-0007zE-3N <= email@example.com H=lb01-ash.bitbucket.org (lb01.bitbucket.org) [18.104.22.168] S=4391 firstname.lastname@example.org T="[Bitbucket] Confirm your email address" from <email@example.com> for ...
However, today it appears that the address firstname.lastname@example.org no longer exists but is still used for your outgoing e-mails, e.g. for password reset messages. As a result many users with stricter spam filtering will be unable to receive these messages from Bitbucket (extract from our e-mail service provider's mail server log):
2013-11-08 17:59:36 H=lb01-ash.bitbucket.org (lb01.bitbucket.org) [22.214.171.124] sender verify fail for <email@example.com>: response to "RCPT TO:<firstname.lastname@example.org>" from aspmx.l.google.com [126.96.36.199] was: 550-5.1.1 The email account that you tried to reach does not exist. Please try\n550-5.1.1 double-checking the recipient's email address for typos or\n550-5.1.1 unnecessary spaces. Learn more at\n550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 q8si1470180wij.48 - gsmtp 2013-11-08 17:59:36 H=lb01-ash.bitbucket.org (lb01.bitbucket.org) [188.8.131.52] F=<email@example.com> rejected RCPT <...>: Sender verify failed
I can understand that you do not want to receive things like bounce messages and auto-replies, but please do not reject DSNs after "RCPT TO" during the SMTP conversation. Either accept DSNs and route them to the bin or reject them after the "DATA" stage during the SMTP conversation.
I hope this bug report helps to bring your system back to the usual reliability we are used to.