Difference between revisions of "Unresolvable Domain"

From Roaring Penguin
Jump to: navigation, search
(How can I make this work?)
m (Why do we reject unresolvable domains?)
 
(13 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
<code>5.1.8 &lt;user@example.com&gt;... Domain of sender address xyz@pqrst.example.com does not exist</code>
 
<code>5.1.8 &lt;user@example.com&gt;... Domain of sender address xyz@pqrst.example.com does not exist</code>
  
Hosted CanIt '''always''' rejects messages where the domain of the envelope sender (in the example above, <code>pqrst.example.com</code> lacks an A or an MX record.  ''This policy is absolutely firm.''
+
Hosted CanIt '''always''' rejects messages where the domain of the envelope sender (in the example above, <code>pqrst.example.com</code> lacks an A, AAAA and MX record.  ''This policy is absolutely firm.''
  
 
== Why do we reject unresolvable domains? ==
 
== Why do we reject unresolvable domains? ==
Line 9: Line 9:
 
If there is a delivery problem, the Internet standards require that a failure
 
If there is a delivery problem, the Internet standards require that a failure
 
notification be sent to the envelope sender (in this example, <code>xyz@pqrst.example.com</code>).  If that domain does not exist, then obviously no failure notification can be sent.
 
notification be sent to the envelope sender (in this example, <code>xyz@pqrst.example.com</code>).  If that domain does not exist, then obviously no failure notification can be sent.
 +
 +
The Internet standards are clear.  [https://tools.ietf.org/html/rfc5321#section-2.3.5 RFC 5321] explicitly says:
 +
 +
<blockquote>
 +
Only '''resolvable''', fully-qualified domain names (FQDNs) are permitted
 +
when domain names are used in SMTP.  In other words, names that can
 +
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
 +
in Section 5) are permitted, as are CNAME RRs whose targets can be
 +
resolved, in turn, to MX or address RRs.
 +
</blockquote>
  
 
== How can I make this work? ==
 
== How can I make this work? ==
  
Only the ''sender'' of the email can fix the problem.  There are several
+
Only the ''sender'' of the email can fix the problem.  There are two
 
options available:
 
options available:
  
# Make sure the domain of the envelope sender address is resolvable.  That is, whatever comes after the <code>@</code> sign in the sender address must have an A record, an MX record, or both.
+
# Make sure the domain of the envelope sender address is resolvable.  That is, whatever comes after the <code>@</code> sign in the sender address must have at least one of an A, AAAA or MX record.
 +
# Use the null return path <code>&lt;&gt;</code> as the envelope sender.  This is useful for situations in which you don't care to receive failure notifications.
 +
 
 +
== Can Roaring Penguin please make an exception? ==
 +
 
 +
No, sorry.  It is an error to send mail from unresolvable domains and the onus is on the sender to fix the problem.
  
# Use the null return path <code>&lt;&gt;</code> as the envelope senderThis is useful for situations in which you don't care to receive failure notifications.
+
== I run my own CanIt serverHow can I allow unresolvable domains? ==
  
If you use an on-site implementation of CanIt, you can work around this by explicitly allowing mail from that hostname [[Allow Non-existent Domains|as described here]]. This should NOT be considered a solution and Roaring Penguin will absolutely NOT do this for Hosted CanIt.
+
Please don't.  Allowing unresolvable domains simply encourages bad Internet
 +
hygiene, ignorance of standards and sub-par programming practices.
  
== But won't Roaring Penguin please make an exception and allow an unresolvable domain through? ==
+
That said, if you want to ignore best current practices and allow such
 +
domains, see [[Allow Non-existent Domains|this Wiki page]].
  
No, sorry.  It is an error to send mail from unresolvable domains and the onus is on the sender to fix the problem.
+
<div style="float:right; clear:both; margin-right:0.5em">[[Support Wiki | [Home]]]</div>
 +
[[category:All]][[category:Management]][[category:Best Practices]]

Latest revision as of 14:27, 19 January 2017

On Hosted CanIt, you may see logs similar to this:

5.1.8 <user@example.com>... Domain of sender address xyz@pqrst.example.com does not exist

Hosted CanIt always rejects messages where the domain of the envelope sender (in the example above, pqrst.example.com lacks an A, AAAA and MX record. This policy is absolutely firm.

Why do we reject unresolvable domains?

If there is a delivery problem, the Internet standards require that a failure notification be sent to the envelope sender (in this example, xyz@pqrst.example.com). If that domain does not exist, then obviously no failure notification can be sent.

The Internet standards are clear. RFC 5321 explicitly says:

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs.

How can I make this work?

Only the sender of the email can fix the problem. There are two options available:

  1. Make sure the domain of the envelope sender address is resolvable. That is, whatever comes after the @ sign in the sender address must have at least one of an A, AAAA or MX record.
  2. Use the null return path <> as the envelope sender. This is useful for situations in which you don't care to receive failure notifications.

Can Roaring Penguin please make an exception?

No, sorry. It is an error to send mail from unresolvable domains and the onus is on the sender to fix the problem.

I run my own CanIt server. How can I allow unresolvable domains?

Please don't. Allowing unresolvable domains simply encourages bad Internet hygiene, ignorance of standards and sub-par programming practices.

That said, if you want to ignore best current practices and allow such domains, see this Wiki page.