Bart Schaefer wrote:
It's certainly possible to handle it that way. However, note that there
are nonzero costs associated with accepting delivery. If the typical
message to my hypothetical support service contains a many-megabyte
coredump (and I have direct experience with users who mail such things
to support addresses), I'd much rather refuse delivery altogether than
have to consume the bandwidth to accept the message and then discard it.
I can see your point.
But in order to avoid consuming bandwidth you need to apply the
filtering rules as part of SMTP negotiation. The information
available at that point will limit your filtering rules to operate
on the addresses of the originator and the recipients as negotiated
by MAIL and RCPT, and possibly some peer information.
I presume that you want to apply one set of rules for each recipient,
after first resolving the address for local delivery, but before
the point where the SMTP server have given a response to the RCPT
command. Am I correct?
If this is the case, a rule that resolve into an action other than
a simple "550 command rejected for policy reasons", has to be
postponed until the SMTP session has been completed, including a
"bounce" in the more reply-like fashion, since you need the complete
message or at least the message header section to complete the action.
I can sense an implementation obstacle here.
On the other hand, I have never tried to implement a complete MTA.
So who am I to write on people's noses how to do things? ;-)
--
Hälsningar/Regards
Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258
TwinSpot is a subsidiary of EuroNetics Operation in Sweden