Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Jul 18, 2014, at 7:50 AM, Ted Lemon <ted.lemon@xxxxxxxxxxx> wrote:
> 
> I must be missing something here.   You're saying you want me to set up a null MX for all my hosts to prevent someone else's MTA having undeliverable mail sitting in the queue for a week?   Why would I care about your MTA's queue?   Why would this issue even be on my radar?

It could be useful as an optimizer to avoid the implicit mx step.  It can also help with any CBV "call back verifiers" support to immediately skip checking the return path dynamically at the SMTP level.  This would provide your receiver with a "55z 5.5.z invalid return path" dynamic rejection at the 5321 mail from or rcpt to state point.

So in this regard, on the receiver side, it is definitely become a valid SMTP compliance check with an enforceable reason to reject regardless of the mail legitimacy. On the sender side, it's an optimizer to avoid the implicit mx attempt.


--
Hector Santos
http://www.santronics.com





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]