Additional SMTP commands might be possible for an ISP to implement
on a client-by-client basis, where individual subscribers decide the
criteria. For this to work, the MTA must know who the intended
recipients are. Therefore, it would have to be done after the RCPT:
stage, where individual recipients are listed. This is not as
theoretical as it may sound. Even though I'm in Toronto, I use clss.net
(Logansport, Indiana, USA) for my inbox. They have a modified Qmail
that parses a blocking config file in the end-user's home directory
after the RCPT: stage. I can accept/reject based on DNSbls, IP address
range, domain, rDNS, etc. So it can be done.
My goal in making this post to ask authors to allow for, and not
preclude, the possibility of their extensions being implemented on a
user-by-user basis.
This kind of approach seems to rely on there being a maximimum of 1 RCPT
per transaction. I'm not saying that's a bad thing (this has been discussed
on the list - and some say it is).
Actually, it's useful for LMTP which requires a separate return code
at the end of the DATA section for each RCPT TO that was accepted earlier
in the LMTP conversation.
However, that is NOT part of ESMTP (it might be nice though).
--
/ \__ | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
\__/ \ | http://www.gamerz.net/rrognlie/ <rrognlie(_at_)gamerz(_dot_)net>
/ \__/ | I can only please 1 person per day. Today is not your day.
\__/ | Tomorrow doesn't look good either.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg