Re: Last Call: draft-klensin-rfc2821bis

Henning Schulzrinne wrote:
> One of the problems I have seen first-hand is "disappearing" mail.  
> Example: A webserver sends outbound email directly, but doesn't want  
> to receive inbound email. The hostname leaks and mail gets sent to  
> that address, based  on the A(AAA) record.

What do you mean by "leaks"?

If it means something other than the domain name of the webserver appears in the 
author's rfc2822.From field address (or, of course, the rfc2822.Reply-To field) 
then your scenario doesn't happen, because those are the only fields that get 
used for return email from a recipient.

Same if/then, with respect to rfc2821.mailfrom and handling notices.

If an incorrect domain name is in an author or return handling address, there 
are bigger problems to solve than AAAA/MX.

If you mean yet something else, then what?

> The mail is "received", but  
> disappears into some never-seen /var file. 

So, a domain name erroneously appears in an address field and the references 
host erroneously accepts mail it shouldn't.

This degree of problematic operation is not likely to get solved with a new DNS 
construct.

If someone is sending out invalid email addresses, then that needs to get fixed, 
rather than working on some post-hoc mechanism.

> Thus, disabling AAAA checking seems to provide much cleaner error  
> behavior. 

Reasonable idea.

Let's do it for all Internet services, not just email.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf