On Thu, 14 May 2009 20:34:57 you wrote:
>
> --On 14 May 2009 11:20:31 +1000 Richard Salts <exim@???> 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 localpart@???. 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/
>
