Autor: David Woodhouse Data: A: David CC: exim-users Assumpte: Re: [exim] support for domainkeys
On Sat, 2004-09-25 at 15:37 +0200, David wrote: > no, but i could supose it is the same as the from address, but maybe
> your srs rewriting has rewrited it to some form of fixed srs address.
No, it's the normally-rewritten SES address. Nothing special -- but my
point was that you haven't seen it and it's not in the archives.
It's only _one_ list which I've found the problem with -- a list run by
ezmlm.
On that list I actually just use a different address which isn't always
SRS-rewritten. So the reverse-path is in fact the same as the address in
the From: header -- it's 'postmaster@???'.
That's not a real solution though -- it's just that I haven't yet
implemented the real solution because it really hasn't been enough of a
problem in reality. It's just that one list so far. The _plan_ is to
have a list of known problematic recipients and to use a fixed srs
address as you said.
> In any case is not possible to mass deploy that system (isp view) as
> any user that uses some of this mailing lists will have troubles
> to send to that mailing lists.
There are many factors which make it not so much of a problem in
practice that it would necessarily prevent deployment.
First, the number of lists run by ezmlm isn't that high -- most are run
by other software and are not a problem.
Second, it's easy enough to keep a list of 'problem' addresses of such
lists, and to do the rewriting differently for those lists so that it
works.
Third, it's trivial to 'fix' ezmlm to look at the From: address instead,
or to extract the original address if BATV standardises the way it's
encoded. The 'fixed address' thing is just a workaround for now
until/unless ezmlm can be fixed.
Fourth, it's deployable per-user. The user can _choose_ to get this
extra protection, if they're willing to always use SMTP AUTH, etc.
More importantly though, I don't _care_ if you don't want to deploy it.
By doing it myself I've stopped getting bounces to stuff I didn't send,
and my users who have opted in to the scheme have also got that benefit.
The beauty of the scheme is that it's unilateral, and it doesn't
_require_ participation from anyone else. That's why it works for
stopping fake bounces, where SPF never will.