Hi folks, My exim install reports the following when bugzilla tries to send me email: 2007-09-29 20:53:40 1IbhRb-00027q-VH H=smtp.gentoo.org [140.211.166.183] F=<bugzilla-daemon@gentoo.org> rejected after DATA: domai n missing or malformed: failing address in "Reply-To:" header is: DO NOT REPLY </dev/null@localhost.> Could we perhaps get that Reply-To header updated to something like?: Reply-To: "DO NOT REPLY" <bugzilla-daemon@gentoo.org> Reproducible: Always Steps to Reproduce:
I set it to: Reply-To: DO NOT REPLY <devull@localhost.> That is valid by RFCs (the previous one was valid as well by selective interpretation of RFCs).
exim still doesn't like it: 2007-10-01 00:07:54 1Ic6x8-000464-4z H=smtp.gentoo.org [140.211.166.183] F=<bugzilla-daemon@gentoo.org> rejected after DATA: domain missing or malformed: failing address in "Reply-To:" header is: DO NOT REPLY <devnull@localhost.> The stanza generating this is (in the data acl): # Check that the email addresses in email headers are syntactically correct: deny message = Incorrectly formatted email addresses in email headers. !verify = header_syntax
could you please state WHY you believe that is invalid? "localhost." is a valid hostname. The trailing dot is important because of dumb MTAs that add their own domain if there is no dot at all.
exim puking on sucky broken checks is not a bugzilla bug.
It's also not a bug with mail-mta/exim per se, however, in the interest of being helpful, i'll take responsibility. This is a bugzilla issue, we should not be setting our reply-to address as soemthing that's not routable, either devnull@gentoo.org or not setting it at all. besides, localhost is not a valid domain in any way, therefore the check is valid, without the . it would be liable to the addition of a domain name part, but with the . you require the user to have no local domain. eitherway, i think the bugzie reply-To is out of spec.
(In reply to comment #5) > besides, localhost is not a valid domain in any way, therefore the check is > valid, > without the . it would be liable to the addition of a domain name part, but > with the . you require the user to have no local domain. Uhm... localhost is a perfectly valid domainname (so is .invalid or .example) plus it's a top-level domain so adding anything to it doesn't make sense. (RFC 2606)
in which case, it's use is invalid, emphasis mine, "To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in _private testing_, as examples in documentation, and the like." from http://www.faqs.org/rfcs/rfc2606.html
(In reply to comment #7) > in which case, it's use is invalid Well, which is completely irrelevant since exim fails to accept .example, .invalid or anything similar in the same way.
those domains are not supposed to be used on the wider internet, therefore exim is correct in rejecting them, it's a sign of mis-configuration at the client end. by default exim attempts to do a sender verify, and that will normally fail as most people don't have the test TLDs configured on their local DNS. setting your reply-to to a non-existing address is bad etiquette.
Either the domain is valid or not; don't please pull etiquette or similar irrelevant stuff into this. Exim behaviour breaks RFCs.
those domains are _not_ valid on the wider internet, as i've said before. Bugzie config is broken, end of story.
(In reply to comment #11) > those domains are _not_ valid on the wider internet, as i've said before. Maybe you could point us to some relevant RFCs which say that they are invalid and define what's "wider" internet? <snip> ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. </snip> Alas, it fails with exim as well - because exim knows better than any other MTA I tried. So, what's your suggested solution? We do NOT want to point the Reply-To to any existing address, because we do NOT want any replies to bugmail sent by bugzilla. Sorry, but exim being smart is plain PITA, and again it breaks RFCs until you prove otherwise.
I had a very specific goal in mind with setting that Reply-To address. If a user just hits reply, and sends some reply without changing the address, I want it to be rejected by HIS/HER ISP's mailserver. I do NOT want it to even attempt delivery to the Gentoo mailservers (noreply@gentoo.org would be rejected at our mailservers only). Given that the actual bugzilla machine runs exim for outgoing mail, I suspect that this is some specific exim configuration issue where the optional check being run against Reply-To is too strict. However, I did do some testing... and I made a very interesting discovery. It is NOT the choice of domain that exim is objecting to. It's the trailing . on the hostname! Jaco will see a bunch of email in his inbox, because I used his server to test it. The only thing I varied in each testcase was the Reply-To string. 1 - Reply-To: devnull@invalid - PASS 2 - Reply-To: do not reply <devnull@invalid.> - FAIL 3 - Reply-To: do not reply <devnull@invalid> - PASS 4 - Reply-To: do not reply <devnull@localhost> - PASS 5 - Reply-To: devnull@localhost. - FAIL 6 - Reply-To: donotreply@localhost.invalid - PASS 7 - Reply-To: donotreply@localhost.invalid. - FAIL EVERY failure is the specific result of the trailing dot. Exim maintainer: please pass to upstream and make them fix the rejection of the trailing dot. It's critical in regards to DNS usage. 'host foo' appends the local domain to foo before the lookup, while 'host foo.' prevents the system from appending. In the meantime, I'm changing Bugzilla to use "Reply-To: DO NOT REPLY <devnull@localhost.invalid>" so that Exim users get bugzilla mail again (as it works around the Exim problem).
Set it to an address that always fails, in exim this would probably be an alias something like: noreply :fail:We do not accept emails on this address That will result in callouts succeeding but any other email bouncing. But then again, that isn't actually the problem here, there are two addresses in play here, the first is the mail from: <> address, which in this case is set to "bugzilla-daemon@gentoo.org" ... this is the address against which callout verifications are made. In general callouts are only made against the From: header IFF the mail from: <> address is the NULL address. It's not a general exim problem though, only a problem with that specific stanza which I use, which catches a LOT of spam without even having to invoke spamassassin. Robin, your assessment of the trailing dot is correct, that stanza only checks the _syntax_ of those addresses, it doesn't actually perform callouts on them, although, I have considered doing at least a domainname callout where I check that at least the domain exists (in which case localhost.invalid will once more fail). Sorry for not participating more in the bugreport ... but alas, I wasn't getting the bugzilla emails.
Jaco: per your "noreply :fail:We do not accept emails on this address" that still means anybody sending mail to noreply@gentoo.org has their server contacting ours, which I want to avoid. the From header is a totally valid address that can be checked (it reaches the bugzilla admins).
Ah sorry, it's the Reply-To: <> that causes issues, not the From: <>. Why not simply use <devnull@localhost> ... I'm aware of the trailing dot issue with the localdomain appended, but it'll in most cases still resolve to 127.0.0.1 and be rejected. Also, "localhost" is in the /etc/hosts file on every single machine that I have ever seen which means that it'll get resolved from there before even going to DNS and having the dnsdomainname appended. Also, some configurations appends the domain name even for localhost.invalid (there is a dot limit on it, see resolv.conf(5) and search for ndots).
progress on this?
o.k. (In reply to comment #13) > I had a very specific goal in mind with setting that Reply-To address. > If a user just hits reply, and sends some reply without changing the address, I > want it to be rejected by HIS/HER ISP's mailserver. I do NOT want it to even > attempt delivery to the Gentoo mailservers (noreply@gentoo.org would be > rejected at our mailservers only). > > Given that the actual bugzilla machine runs exim for outgoing mail, I suspect > that this is some specific exim configuration issue where the optional check > being run against Reply-To is too strict. However, I did do some testing... > > and I made a very interesting discovery. It is NOT the choice of domain that > exim is objecting to. It's the trailing . on the hostname! > Jaco will see a bunch of email in his inbox, because I used his server to test > it. > The only thing I varied in each testcase was the Reply-To string. > 1 - Reply-To: devnull@invalid - PASS > 2 - Reply-To: do not reply <devnull@invalid.> - FAIL > 3 - Reply-To: do not reply <devnull@invalid> - PASS > 4 - Reply-To: do not reply <devnull@localhost> - PASS > 5 - Reply-To: devnull@localhost. - FAIL > 6 - Reply-To: donotreply@localhost.invalid - PASS > 7 - Reply-To: donotreply@localhost.invalid. - FAIL > > EVERY failure is the specific result of the trailing dot. > Exim maintainer: please pass to upstream and make them fix the rejection of the > trailing dot. > > It's critical in regards to DNS usage. 'host foo' appends the local domain to > foo before the lookup, while 'host foo.' prevents the system from appending. > > In the meantime, I'm changing Bugzilla to use "Reply-To: DO NOT REPLY > <devnull@localhost.invalid>" so that Exim users get bugzilla mail again (as it > works around the Exim problem). > I've finally managed to get my head around this, and there are a couple of misleading comments going on, but i'll deal with the easiest first, why exim thinks "DO NOT REPLY </dev/null@localhost.>" is invalid. Warning, this is going to get specific. Remember the check is a "syntax' check rather than a symantic, ie, is is valid, rather than does it make sense. So, looking at the rfc for Internet Message Format (rfc 2822), what is the format for the Reply-To field, Seconf 3.6.2. Originator fields specifies, reply-to = "Reply-To:" address-list CRLF so what is the format for 'address-list'? Section 3.4. Address Specification, address-list = (address *("," address)) / obs-addr-list so an address list is a one address optionaly followed by a comma an another address (and so on), or an 'obs-addr-list' (which i'll ignore for now as it's obsolete) so, what is an address? Section 3.4. Address Specification, address = mailbox / group I'll ignore a group for now, but suffice to say it boils down to a set of addresses, so, what is a mailbox? mailbox = name-addr / addr-spec as the first eventually becomes the second via the addition of some quotes and angle brackets, I'll skip the full explanation and jump to the addr-spec Section 3.4.1. Addr-spec specification This is the bit we need, addr-spec = local-part "@" domain so, we need to know what a domain means in this context. domain = dot-atom / domain-literal / obs-domain so ignoring obs-domain, lets first look at domain-literal domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] so, to skip a bit, a domain-literal is the domain interpreted as the literal Internet address of the particular host., forex [mailhosttest.gentoo.org] so, back to the dot-atom. 3.2.4. Atom defines dot-atom as: dot-atom = [CFWS] dot-atom-text [CFWS] so dot-atom-text dot-atom-text = 1*atext *("." 1*atext) so atext? well, that's any character except controls, SP, and specials. so, to expand dot-atom-text it's 1oad more atext tokens, followed by one or more blocks of a "." followed by one or more atext tokens. Note: there is no trailing dot, it's blocks of text/with "."'s between. <===== END OF LONG EXPLANATION ======> so, why do we think a trailing "." is valid, well, its part of the behavior of the stub resolver on a host to try and expand a host with an apppended domain name if a host doesn't have a trailling "." So, I believe that the syntactic check being done by exim is correct, as a "." should only appear between text in a domain. Jaco: i think Robbat's current fix of setting the Reply-To to "Reply-To: DO NOT REPLY <devnull@localhost.invalid>", will fix the problem you're seeing, whilst still preventing emails turning up at bugzie. So, i will not be escalating this upstream, I believe the check to be correct. (the selection of domain used is another matter for another day, and directly relevant to the original problem). Cheers, Colin morey
> > (the selection of domain used is another matter for another day, and directly > relevant to the original problem). > sorry mis-typed, and _not_ directly, (the selection of domain used is another matter for another day, and not directly relevant to the original problem). Cheers, Colin
(In reply to comment #18) > Jaco: i think Robbat's current fix of setting the Reply-To to "Reply-To: DO NOT > REPLY <devnull@localhost.invalid>", will fix the problem you're seeing, whilst > still preventing emails turning up at bugzie. Yes and no. It's valid, but invalid. It's a valid domain name according to the syntax check for the Reply-To. I have however quickly checked the Return path and from headers as well. These are both set to bugzilla-daemon@gentoo.org which also avoids the sender verify callout problem that would pop up in the case of the return path also being set to something invalid. I'm personally quite happy with the current configuration. > So, i will not be escalating this upstream, I believe the check to be correct. So do I. Well, the trailing dot does make sense for normal DNS resolution, but I've never seen short domain names used on incoming email addresses, so the trailing dot makes sense from one arguments side and at the same time it doesn't. Thanks for the feedback. As far as I'm concerned you're welcome to close.
O.k. Closing this bug out, if anyone has any comments about the choice of domain or whatever, please open a separate bug.
