Sorry for the possibly naive question, but why would you actually
*want* the SMTP callback to work. Suppose you are using BATV or
something like BATV, and you send mail to someone whose client is
infected by a virus. That person's computer might then turn around
and send 1,000 messages from your envelope sender address. Or maybe
the BATV shows up in a Return-Path: header of some web archive, and a
spammer picks it up there.
As if someone sends a message to me (real message) and their mail server
does a callback to see if the email address they are going to send to
is real before they accept the email from the user then rejecting with
<> only will tell the other mail server its an invalid adderss. rejecting
after the data will make sure its a real message.
BATV as far as I know doesn't have any timeouts on its return paths
(well in exim's version of it), but SRS does. (ie the return path is only
valid for a week or whatever you set ). with BATV, it looks like the
return paths are valid forever so yes someone could come along and use
a return path to email me.
Either way, if recipients of the forged messages implement SMTP
callbacks, it seems to me you want to inform them that you are not
interested in receiving bounce messages to that address. Especially
since, under most of the scenarios under which I can imagine a bad guy
getting the sender address, the original message has already been
delivered.
I would argue that the right thing is not only to use a unique sender
address for each message, but also to accept a limited number of SMTP
callbacks for the address--maybe something like 5 + 5 times the number
of recipients. Saving bandwidth from a DATA command you are going to
reject sounds like a relatively minor optimization compared to helping
forgery recipients reject the forged mail.
They way I am doing it at the moment. allows callbacks from remote SMTP
to see if the email addersses are real and it stops 100% bounces which did
not come from me (as they are not signed). It works, but the time factor
in the BATV being valid maybe a problem if people start to try and spam
people from <> and use my return path to send it to
2006-02-17 05:27:17 1F9lyO-0002CA-P2 H=dsl9.21.ic.net
(WM000001.weldmold.com) [152.160.21.9] F=<> rejected after DATA: Invalid
BATV Bounce
2006-02-17 05:54:49 1F9mP2-00034U-Kw H=mail.isla.net [12.16.41.2] F=<>
rejected after DATA: Invalid BATV Bounce
2006-02-17 05:55:19 1F9mPX-00035T-3Y H=(ar33.toservers.com) [200.62.55.133]
F=<> rejected after DATA: Invalid BATV Bounce
2006-02-17 05:58:24 1F9mSW-0003Al-EH H=bigbird.whtech.com [64.125.72.2] F=<>
rejected after DATA: Invalid BATV Bounce
2006-02-17 06:22:20 1F9mpg-00047F-Co H=qsrv03ps.mx.bigpond.com
[144.140.82.183] F=<> rejected after DATA: Invalid BATV Bounce
Thanks
Craig
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com