Returning to Fridrik's original points
1) The bounce messages are unwanted and indiscriminate, therefore they are
by my definition spam.
2) If RFC 2821 offends thee, pluck it out.
At this point the IETF has had a chance to fix SMTP and failed. I
would rather that messages were dumped on the floor than have bounces sent
to clearly false addresses. The chance of a false positive on a pattern
detecting virus scan in particular is very very small. The amount of
iunnecessary concern that is caused by these messages is very large. I think
that the reason that companies keep sending this stuff that thy know is
hitting an innocent bystander is that they think it's a cute advertsing
trick. The fact that it is telling everyone who receives it they are
clueless does not sink into the marketting thickos.
3) You can protect yourself against false bounces
A better solution would be to deploy BATV or some variant and in
effect give yourself the ability to validate your own bounces by adding a
validation cookie to the 821 FROM address, the bounce address. This will
still leave you with spam from non conformant mail servers.
4) Better would be an out of band form of signalling.
The bounce problem is the result of using the email channel for both
control and data. It is a poor design which was acceptable in circa 1980
when SMTP emerged as an improvement on the send mail through FTP hack. A
useful extension to SPF would be a signal to say 'if you have bounces please
report them via this Web Service rather than in channel'. The work going on
in INCH could be reused.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg