Re: [exim] Sender callout verification on BATV signed addres…

Góra strony
Delete this message
Reply to this message
Autor: Ian Eiloart
Data:  
Dla: Richard Salts, exim-users
Temat: Re: [exim] Sender callout verification on BATV signed addresses


--On 18 August 2009 19:36:21 +1000 Richard Salts <exim@???>
wrote:

> On Mon, 17 Aug 2009 19:38:41 you wrote:
>>
>> --On 15 May 2009 11:33:15 +1000 Richard Salts <exim@???>
>> wrote:
>>
>> >
>> > 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.
>>
>> It's too late to worry about this. Already several important domains
>> publish spf records with "-all", and some large email providers like
>> Google use spf records in their spam assessments.
>>
>> You can see a list of top domains with spf "-all" records at
>> <http://spf-all.com/>.
> The litmus test is not people publishing spf records with -all, but
> people rejecting based on this policy. If enough people in a business
> start complaining about emails being rejected from a -all policy it's a
> simple matter for a local administrator to change it back to ?all.


There isn't a litmus test. There's a gradual progression from a world where
"MAIL FROM" tells you nothing, to a world where you can assign reputation
to the sender address given (or its domain). It'll take years, but it has
to be done. What we'll see is a gradual increase in the domains publishing
SPF, a gradual increase in the proportion using "-all", a gradual increase
in recipients respecting the published policies. We'll also need to see a
completion of rollout of MSA, and improvements in forwarding practices.

The choice that email admins need to make is: where on the spectrum do they
want to be at any given time?

Right now, I'd not advocate using "-all" unless your domain is particularly
attractive to phishers. I'd certainly advocate it for financial
institutions, who should have current email addresses for customers in the
same way that they should have current postal addresses.

>>
>> If you're forwarding mail for your users without rewriting the sender
>> domain, then you should expect some of that forwarding to fail.
> The problem with this is that if you're forwarding the email around
> through too many hops the localpart on the envelope sender is eventually
> going to be too long to be a valid email address, especially if you're
> using a cryptographic hash in the envelope of the rewritten sender. Not
> using a hash opens you up to spammers being able to create backscatter
> spam through your forwarding service by forging a bounce to their
> rewritten sender address.


There are various ways of rewriting sender addresses. The point is, you
have to use one or more of them depending on the local circumstances,
otherwise some of your customers' mail won't get delivered.

In fact, you don't have to rewrite all the mail that you forward. You
certainly should not forward email that gets an SPF hard fail. You can
safely rewrite mail that gets an SPF pass, and you can safely bounce it if
you can't forward it. You shouldn't rewrite email that gets an spf
softfail, or for a domain that doesn't publish spf records, and you should
be cautious about forwarding it if doing so would improve the spf result!


>>
>> SPF will cause some pain for the next few years, while forwarders catch
>> up. In the end, it'll give us a huge benefit of allowing us to assign
>> reputation to a sender address - before we see the body of an email.
> A reputation service on sender address would be great. But I don't think
> it's that much more helpful than the current ip based reputation
> services. Admittedly it's much more intuitive to end users of email, but
> I think most of them will probably handball the task to their email
> administrator, or would quickly be able to grasp the current disconnect
> between domain reputation and ip address reputation.


"It's more intuitive to end users" is exactly the point. My users want to
whitelist various correspondents by email address, not by IP address. I can
create a web tool to allow whitelisting by sender address. I can't do that
for IP addresses. Heck, I wouldn't even if I could - far too many IP
addresses emit a mix of wanted and unwanted mail.

And, consider this: an email from an IP Address owned by "live.com". Is it
more useful to be able to whitelist specific senders? Is it more useful to
be able to assign reputation to specific senders? Or, do you want to treat
all "live.com" users as equal?

>>
>>
>> --
>> Ian Eiloart
>> IT Services, University of Sussex
>> 01273-873148 x3148
>> For new support requests, see http://www.sussex.ac.uk/its/help/
>>
>
>




--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/