On Thu, 14 May 2009 20:34:57 you wrote: > > --On 14 May 2009 11:20:31 +1000 Richard Salts <[email protected]> wrote: > > > On Wed, 22 Apr 2009 06:09:13 Bryan Rawlins wrote: > >> So my question is, and I'm strictly looking for personal opinions here; > >> Are callout/callback verifications on the envelope sender when that > >> sender is signed more acceptable than just doing them in general? > > If people don't want callback verifications to their sites in response to > spoofed email, then they should publish information about where their mail > comes from. There are three cases: > > An email verifies with SPF or DKIM or similar - the callback may be > regarded as pointless, but it should not be unwelcome. Bounces, > autoreplies, and so on should all be acceptable.
I'm not advocating callback verification, because although it can be effective for a small number of people it's also very damaging to the system in general. A tragedy of the commons waiting to happen (similar to challenge response) and also not a good indicator that a message is spam (although it seems to work some of the time at the moment especially if the envelope is signed with BATV and the domain owner is trustworthy). > > SPF, DKIM or similar tests fail. Don't do the callback, don't accept the > message. If you do accept the message, make sure that it is not later > bounced, and that autoreplies aren't sent. I'm not sure that SPF is such a great utility, except for whitelisting valid senders emails. Receiving a message from a host not listed for the domain isn't a good indication that the email is a forgery, as forwarding breaks this assumption. I agree that DKIM is a good solution for forgery, however it relies on both the sender and receiver of a message changing their behaviour. What I was suggesting was for the domain to signed for a sending server. This means that the recipient has to do no more work than verify the existence of a domain name, which most people are already doing, and the envelope sender will be verified. For instance using the BATV domain variant I'd send out emails with a signed envelope such as [email protected]. My trick dns server would then only publish the record for a specific TAG as a subdomain with a time to die of 2 days or so, which should mean there is plenty of time for the mail to be delivered. On the recipients system there is no change, they're not performing callbacks, except for the usual dns query to check that the address comes from a domain that exists. They don't have to check any DKIM signatures, or SPF records, and the message is still known to be sent by the domain owner with not further effort on the receivers part. > > SPF, DKIM, or similar tests are inconclusive. In an ideal world, we'd never > see any such email. What you do here depends on your mood. As the world > moves to more widespread adoption of technologies that allow us to detect > spoofing, you'll find yourself here less frequently. Callouts, bounces and > autoreplies should encourage people to deploy such technologies. I'd that > we should defend the utility of e-mail by being unembarrassed about > auto-replies and callouts when we can't verify the domain. In time, we > should lose our inhibition about bouncing messages of uncertain origin; > when they fail other spam tests. Perhaps, one day, all legitimate email > will pass spf, dkim or similar tests. > > > > Tony Finch mentioned at some point toying with BATV but suggested signing > > the domain rather than the local part. It requires more infrastructure, > > such as a trick dns server to host the subdomains which are signed, but > > it could be a way for BATV to be used as an authenticity test without > > leading to the heavy penalties to the domain owner of SCV. I think it > > might have other disadvantages such as a big impact on caching resolvers > > and dns traffic, possibly even decreased reliability. But it seems to me > > that dns scales a lot better than smtp servers, given the number of RBLs > > using it as a mechanism to publish very dynamic data. > > > > -- > Ian Eiloart > IT Services, University of Sussex > 01273-873148 x3148 > For new support requests, see http://www.sussex.ac.uk/its/help/ > -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
