Re: spf entries for which hosts ???

--Commerco WebMaster <Webmaster(_at_)Commerco(_dot_)Net> wrote:

> 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.

I think that you might be conflating the two concepts, of reporting to the 
domain owner vs. bouncing or rejecting the message.  (I apologize if I 
misunderstood you -- if the following is not at all relevant you may ignore 
:)
If a message is really forged, the best possible case is to not accept it: 
reject it during the initial transaction.  If you don't reply 2xx to DATA 
then you haven't officially accepted the message and you don't have to do 
anything to report the failure other than closing the connection.
If you have accepted the message and then later figure out by SPF that it's 
a forgery, well, you poor bastard.  Following traditional email practices, 
you would need to send a bounce message to the original sender.  There is 
no rule that says you shouldn't.  Traditional (i.e. old) wisdom is that 
it's better to notify someone of the bounce than to drop mail on the floor. 
Some might say that if you can prove using SPF that it was a forgery that 
maybe you shouldn't send the bounce.  More and more people are starting to 
complain about "accept-then-bounce" aka. "blowback" and many hard-core 
anti-spam folks will block servers that bounce forged messages too much. 
There's no hard and fast rule, but most, probably all email server 
operators would agree that it's much much much better if you can arrange to 
just not accept the forged message in the first place.
Now... neither of the above have to do with report= and here is why.  If a 
message is rejected due to SPF, it's likely to be a forgery, and in that 
case, the domain owner and the sending server are probably not the same. 
So by rejecting the message during the initial connection, you have made it 
the sending server's problem to deal with, but it's likely that the REAL 
domain owner has no way of knowing that the attempt was made and failed. 
He has no way of knowing that his domain is being used, abused, or possibly 
even being prevented from sending something he wanted to send but hasn't 
properly configured (like sending from a hotel or something).
Normally you would not go to the effort of notifying the (real) domain 
owner that the (unauthorized) mail server just tried to do something and 
failed.  report= and exists:+logging are two possible ways to get around 
that and alert the real owner of the domain that something fishy is going 
on, and SPF is probably working correctly (but if he really meant to send 
something he should examine his SPF record)
So.  I would recommend to set your site's policy regarding "bounces" 
totally separately from SPF report= parameter.  If you can manage it, 
reject the messages up-front rather than accepting and then having to 
choose between a "blowback" bounce and dropping to a black hole.  Rejecting 
up-front makes it the problem of the sending server (which might send a 
bounce anyway but that's for them to decide -- if it's a direct spammer or 
virus it will just move on to the next target anyway).
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>