Re: [exim] Domain Keys

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Ian Eiloart
Fecha:  
A: Richard Clayton, exim-users
Asunto: Re: [exim] Domain Keys


--On 11 April 2007 14:04:53 +0100 Richard Clayton <richard@???>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <91CAD6AB736DAE8E58B0E432@???>, Ian
> Eiloart <iane@???> writes
>
>> Why? If users here want their email forwarded to another account, they
>> have to tell us about it.
>
> yes of course
>
>> It's not so much extra work for them to do something
>> similar at the destination site.
>
> That's a strange claim!
>
> Why do you think BT, Demon, NTL, Earthlink or whatever would be in the
> least bit interested in doing something special ? or want to know ?


Well, that's an interesting challenge. If they want SPF to take off (and
clearly MS do, since they publish records), then they have to do something
sensible.

The problem with this thread is that people are asking questions about
whether SPF is workable right now. They should be asking questions about
whether there's a pathway to making it work.

I think there is, and that the world is moving down that pathway. I think
the pathway looks like this:

1. Publish records that are usable for whitelisting, or spam scoring. This
only has to be done by a proportion of the world to be useful.

2. A proportion of the world has to respect SPF records. It's quite
legitimate to respect all SPF records, since the domain owner is publishing
a policy that they want enforced.

3. At this point, providers may begin to notice that they have to do
something about mail forwarding. For example, I might have to tell my
provider to expect email that's forwarded from a specific address - they
could then whitelist the SPF published servers for the domain that I'm
forwarding from - for me only.

4. Also, and we're already a long way down this path, domains must offer
authenticated SMTP on port 587, so that users can use the correct relays.


> I've just had a look at http://www.sussex.ac.uk/its/email/detail.php and
> I can't see any warnings (or any way to tell Sussex) about email
> forwarded _to_ that site....


No, we don't use SPF yet. I guess we'd offer it as an optional level of
protection - on by default. And, we'd ask people to switch it off (for the
target account) if they had a problem with it.

> ... it's quite an achievement if people who are forwarding their email
> remember to turn off the spam detection at the destination and thereby
> reduce the backscatter! I recently did some figures on this and found
> that 3.5% of the email coming into Demon was forwarded and 66% of it was
> not accepted because it was spam.
>
> Whether that 66% getting a 5xx meant a DSN was created by the sender
> will of course depend upon the configuration of the sender... [cue:
> something on-topic, how best to arrange NOT to generate a DSN after a
> rewrite earlier on...]
>
> Anyway, does Sussex monitor for people who cause this backscatter
> whether they "do something similar" at the destination site or not ?


No, we don't. We should, I suppose, but I'm not sure what. We do
call-forwards before accepting the email, and that ought to take care of
spf rejections, I think.


--
Ian Eiloart
IT Services, University of Sussex
x3148