[ On Friday, June 24, 2005 at 10:45:51 (+0100), Philip Hazel wrote: ]
> Subject: RE: [exim] a large number of domains fronted by Exim are refusing bounces...
>
> Why not? It is perfectly legitimate to reject bounces to addresses that
> never send mail, and many sites want to do that.
Well if those addresses don't exist in the first place then that's fine,
but of course one doesn't need to know the sender address in order to
reject mail destined to those non-existant addresses.
However if those addresses do exist then they _MUST_ accept valid
messages, from valid sources, especially when those messages are sent
with a null return path.
Delivery error notifications are far from the only kind of message which
might (and in some cases "SHOULD") be sent with a null return path, as a
quick grep through the current RFC corpus will reveal, never mind all
the other non-standardized uses.
> Furthermore, as many
> sites start to adopt various ways of signing sender addresses, they will
> want to reject bounce messages to unsigned addresses
That doesn't quite make sense -- even in the context of the silliness of
"signed sender addresses".
Legitimate sources of legitimate e-mail will still have valid reasons
for sending messages to any valid addresses, and for using the null
return path when doing so.
On the other hand someday one might be able to at least tag as very low
priority any unstructured messages arriving with a null return path (and
also automatically deal with all such structured messages).
However one must not confuse transport features and content control
features. That's a major protocol layering violation, and in this case
probably a duty better suited to the MUA, not the MTA.
(That said I'm all for blocking MUAs which abuse SMTP for message
submission and which as a result have grown warts which cause them to be
able to generate their own "fake" bounce messages, etc. However that's
a site-local problem, and one which be handled internally to an
implementation by providing means to identify hosts which are expected
only to be running basic MUAs. I'm no fan of abusing null return paths
for automated user agents either, but it's done all the time anyway, in
part because RFC 2852 isn't anywhere near universally implemented and
also of course because most everyone's too afraid to rely on
non-standardized features such as the Precedence: header.)
> in order to block
> collateral spam (aka Joe Jobs).
There are lots of ways to do that.
Blocking such junk because it uses a null return path is the most
incorrect solution, and it's what has lead to the likes of
dsn.rfc-ignorant.org where we have to list such abusers to try to get
them to change their ways.
> Removing that facility of testing for the empty string would be
> detrimental to these other uses.
True enough, if one considers those uses more important than providing a
robust way of handling the required in-band error notifications and so on.
> And anyway, it would be hard to do
> completely. "The empty string" can be represented in many ways in Exim:
> as a literal string, as a regular expression that matches an empty
> string, as a database lookup that matches an empty string, etc., etc.
You could transform the null return path into some special internal
representation that cannot be represented in the ACL expression syntax,
for example. (e.g. something similar to the difference between a nil
pointer and a pointer to an empty string, one of which can be
represented in the syntax, and the other which cannot)
In any case that's why I suggested the alternate way of making it more
difficult for the special case of a null return path being presented to
ACL rules in the first place. Let the admin write ACLs which will try
to block null return paths, but don't let the special case of a null
return path "match" in those particular expression terms. For example
in Smail, which does not and will not ever cater to the idea of defering
verification and validation to some subsequent command in the
transaction, this means not even running any of the sender address
verifications, or access controls, or trying to look it up in any of the
RHS DNSBLs, in the first place if it is the null return path (or the
special internal null return path).
This latter approach makes it possible to use a representation of the
null return path in rules which govern delivery, e.g. to allow for your
example of spooling all such messages to a special folder, but not be be
used explicitly in any access control.
Some combination of these approaches might be necessary to allow for
RCPT TO: ACL expressions of this sort:
IF $sender IS "<Jordy>" AND $recipient is "<Data>" THEN
reject_recipient("Data doesn't love Jordy any more.")
but to not allow the likes of this to ever have any actual effect:
IF $sender IS "<>" OR "" AND $recipient is "<Data>" THEN
reject_recipient("Data doesn't like error notifications.")
i.e. Data would get his error notifications, vacation messages and
whatnot regardless of his desire (assuming they passed all the other
access controls that did not depend on $sender).
Meanwhile for final delivery rules there could be a context sensitive
special identifier which would match the null return path:
IF $sender IS $the_null_return_path THEN
file_message(/var/mail/bounces)
and that special value would only be allowed in expressions related to
message handling, not in access controls. I.e. an attempt to write an
ACL which uses the special value, e.g.:
IF $sender IS $the_null_return_path AND $recipient is "<Data>" THEN
reject_recipient("Data doesn't like error notifications.")
would result in a syntax error:
"$the_null_return_path special token used in an invalid context."
There are no shortage of ways to make error handling more robust despite
the intentions of ignorant and mis-informed admins who would try to
break it, despite the desire to have as flexible an access control
language as is conceivable.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
