Meng,
At 03:44 PM 10/11/2004, you wrote:
On Mon, Oct 11, 2004 at 01:40:00PM -0600, Commerco WebMaster wrote:
.. snip my question, below part of your answer ..
There are two ways to report this information back to domain
owners: they can use an "exists" for logging, or they can
help develop a reporting syntax, eg. v=spf1 -all report=postmaster+spf(_at_)%{d}
Thank you for this. A more elegant solution than my original thought, as
you can specify a report return address. Perhaps we might want to add a
report=NULL option or something like it to specially inform the requester
explicitly that they should not send a bounce message for authentication
failed SPF events.
The original reason I asked about this was that we are seeing some well
known AV software sending bounce messages on forged spam sent out with one
or two of our names lately, so I am hopeful they will adopt SPF in their
software to avoid these bounces and not deliver bogus "from" messages. As
I thought about that, my mind went to evidence gathering and having an
ability to have the spammed hosts's AV software report the identity theft
abuse back to me anyway, even given published SPF records and not just in a
550 condition. Although, sending back information on deliverable messages
to the abused domain owner might be a very bad idea, as I could easily
envision spammers using that as a mighty fine tool for address
verification. Still, I think that the ability to control reporting of
undeliverable bounce messages that fail SPF is a nice capability.
In the reporting syntax, may we also presume that if the 'report=' part is
not included in the SPF TXT record, the correct behavior would be to drop
the message and not report the abuse back to the abused domain owner via a
'<>' delivery bounce return? If so, then the report=NULL option I
suggested above is redundant.
Best,
Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/