On Sat, 24 May 1997, Dr. Rich Artym wrote:
> Let's not forget one very important use of invalid sender addresses
> though, namely for preserving anonymity.
Let's not forget one very important use of valid sender addresses
though, namely for sending delivery failure reports to. There are 19
messages on the queue on our student server. Every single one of them is
a delivery failure report for a bit of incoming spam that we didn't
manage to catch in time. Every single one of them is addressed to an
address that is failing to get delivered (typically "user unknown").
There are 26 similar messages on our general server (out of around 50).
This means that the incoming spam had sender addresses that verified, in
that their domains were valid, but the local-parts weren't.
I get very pissed off by this. We don't set verify_recipients, in order
to be able to send back to genuine senders a more helpful message than
just "user unknown" - it either says "this account has been cancelled"
or gives information about common typos in our login names and about
finding people at Cambridge. I consider this to be a useful service to
the email community. The increasing amount of spam with addresses that
appear valid but in fact are not is putting on pressure to turn on
verify_recipients, thus degrading the service we provide.
We could alternatively turn on ignore_errmsg_errors and thereby just
drop delivery failures that fail. This would mean that genuine problems
would not be seen, again degrading the service.
I fear that one or other of these will get done sooner or later, as the
exponential increase in spam exhausts my patience.
> Invalid sender addresses are
> not in themselves bad,
Yes they are, because the RFC says they are where you send error
deliveries to. There ways of sending anonymous messages if you really
want to, without using an invalid envelope sender.
> What's important in
> an MTA is to be able to allow invalid addresses through if the admin
> wishes to do so,
With that I can entirely agree.
> Hopefully this list is about perfecting the very nice general mechanism
> of Exim, not about implementing any specific policy which individual
> developers and administrators may have.
Indeed. That is why Exim has sprouted so many options...
> On this list, the issue should
> be not how the developer or administrator feels about spam, but how we
> can make Exim implement each ****END USER'S**** spam-filtering wishes.
... AND the administrator's wishes. There are institutions and companies
that do have institution/company-wide policies that they want to impose
at the top level. Exim should be able to accommodate them as well.
Philip
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
