Szerző: Marilyn Davis Dátum: Címzett: David Woodhouse CC: exim-users, Nigel Metheringham Tárgy: Re: [exim] Anti Phishing Trick
On Wed, 24 Aug 2005, David Woodhouse wrote:
> On Wed, 2005-08-24 at 13:01 +0100, Nigel Metheringham wrote:
> > The problem is that SPF works fine if you look at it from the
> > perspective of an individual (with clue) - I know how my (legitimate)
> > mail gets to me, and can allow for that (so stuff thats being
> > legitimately forwarded via my vanity account with the federation of
> > yorkshire jelly wrestlers can be allowed for).
>
> How do you know which machines the federation of yorkshire jelly
> wrestlers will be using for forwarding mail? It won't necessarily be the
> MX hosts for their domain, and it won't necessarily be the normal
> outgoing mail servers listed in their SPF record (even if they _have_ an
> SPF record). If you come up with some list of addresses which you think
My understanding, please correct me, is that The Federation of
Yorkshire Jelly Wrestlers is responsible for maintaining the right
info in their SPF record. So if they are sending from a different
machine, then the failure of their mail to complete is the
Federation's problem. They *should* realize that their SPF record is
inaccurate when mail bounces for this reason, and then fix the
problem.
And I'm thinking that, if mail comes from the wrong machine, according
to SPF record, and local_part@domain is on the To: header, then the
mail was not forwarded and is definitely phish. If the To: header
does not have local_part@domain, then either it is non-personal-bulk
(which phish wouldn't be) or it was forwarded and the MTA who first
received the phish can be blamed.
If some company is phish-bait and does not maintain an SPF record,
then they are to blame for not doing the best they can to prevent
phishing in their name.
I'm not really into assigning blame, but responsibility.
Marilyn Davis
> is accurate, what makes you think it'll still be accurate tomorrow?
>
> So no, even for the individual with their own private mail server it
> doesn't really work that well for rejecting false mail. And when you
> start trying to apply it to recipient domains with a large number of
> users, each of whom may have different forwarding arrangements, it's
> basically impossible.
>
>