On Nov 30, 6:20pm, Hector Santos wrote:
}
} ----- Original Message -----
} From: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>
}
} > } receiver-SMTP MUST formulate and mail a notification message. This
} > } notification MUST be sent using a null ("<>") reverse path in the
} > } envelope. The recipient of this notification MUST be the address
} > } from the envelope return path (or the Return-Path: line). "
}
} > [That] is not a requirement that the original sender accept it.
}
} Thats a non-issue. Unrelated really. A Callerid Verification system is
} not sending mail. Half the battle is solve by being able to connect or
} not connect and reaching the RCTO TO: stage.
Another example:
As a SourceForge project administrator, I get notices of system upgrades
or downtimes and so on. These messages are MAIL FROM: an address similar
to <do-not-reply(_at_)sf(_dot_)net> (I forget the exact address).
If such a message arrived at a host using your caller-ID system, your
system would connect to the sf.net MX, issue "MAIL FROM:<>" and then
issue "RCPT TO:<do-not-reply(_at_)sf(_dot_)net>". Right so far?
The point that Yakov tries to make is that there is no RFC requirement
that sf.net respond "250 recipient OK" when presented with that RCPT TO:.
In fact, it probably responds "550 user unknown". There is also no RFC
requirement that sf.net's sending server knows, at the time that it says
"MAIL FROM:<do-not-reply(_at_)sf(_dot_)net>", exactly what response sf.net's MX
may
give when presented with that address as a RCPT TO:.
Your system would thus reject this perfectly legitimate message. The
fragment of 2821 that you quoted above does not justify your use of this
RCPT TO: test for sender validity. Is there some other standard that
you believe does justify it?
} But with that said, the receiver must accept a NULL address.
In MAIL FROM:, yes. That part truly _is_ unrelated to Yakov's point.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg