In
<1120576546(_dot_)19467(_dot_)202(_dot_)camel(_at_)hades(_dot_)cambridge(_dot_)redhat(_dot_)com>
David Woodhouse <dwmw2(_at_)infradead(_dot_)org> writes:
I misspoke. The only feasible way they can support forwarding is to
refrain from rejecting mail for an SPF failure.
I still disagree that the only "feasible way" for mail receivers to
support forwarding is to not reject on SPF failures. But, we are just
rehashing the same old arguments and getting now where.
Forwarding without rewriting the 2821.MAILFROM also causes problems
with bounces because the sender will receive a bounce from some place
that they never sent email to.
That's not a _problem_ though. That's just normal operation. It's worked
that way for years.
Uh, I disagree. That *is* a problem. Just because it has been a
problem for many years doesn't mean that it isn't a problem. It has
become a much worse problem in the last 5 years or so than the
previous 20 years because so much spam has spoofed identities.
No, spam with spoofed identities has nothing to do with 'problems'
caused by forwarding without changing the reverse-path. In the case of
_fake_ mail it doesn't _matter_ where I receive the bounce from --
whether the forwarder does SRS and the bounce comes back indirectly, or
whether the forwarder is just behaving normally and the bounce comes
back directly from the final recipient. I didn't actually send mail to
_either_ of them, so why would it matter where the bounce comes from?
Again, this kind of forwarding will likely get you listed on things
like spamcop's DNSBL. That is something that wouldn't have happened
10 years ago.
What precisely is the problem which you think exists?
The other problem is I send an email to <user(_at_)somedomain(_dot_)tld>, which
then forwards it on to <somename(_at_)final-dest(_dot_)tld>. If I receive a
bounce back from final-dest.tld, I may have no idea which email
triggered the bounce. The bounce could happen days later if
somedomain.tld had to queue and retry sending the email. Not all
domains do a good job of giving enough information in their bounce
messages to be able diagnose this situation.
There is also the problem that such bounces leak information about who
the final destination is, something that some people will not like.
Neither of these problems have anything to do with SPF or spam.
Anway, my point remains that "classic alias forwarding" has problems
in today's email environment, and not just due to SPF.
-wayne