Mailing List Archive

On Saturday 14 April 2007 15:45, Adrian de los Santos wrote:
> Phisinhg is hitting the accounts of my servers, and this is because
> spf only checks the envelope-from of the mail transaction and not the
> From: in the data transaction, so the spammers/fhishers are using a
> different from data
>
> In the From: of the data transaction they have mail accounts from
> financial institutions (and it does not matter that the domain of the
> bank has spf enabled, the current implementations of sfp does not
> check the from: of the data transaction).
>
> There is any implementation of spf that checks the from of the data
> transaction ?

Not that is actually useful. There are valid reasons for Mail From and From
to be different (look at the header of the e-mail for example).

> How can i prevent forged froms on the data transaction ?
>

This is a difficult problem. SPF is only a part of the solution to a bigger
problem.

What MTA are you using? We might be able to suggestion specifics.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Sat, 14 Apr 2007, Adrian de los Santos wrote:

> There is any implementation of spf that checks the from of the data
> transaction ?

No. Sender-ID could have been, but it checks some random header chosen
by the spammer. (Well not random, but using a patented algorithm.)

> How can i prevent forged froms on the data transaction ?

Use DKIM. This requires the sender to sign their headers, and publish
a public key in DNS.

However, SPF will indirectly suppress forged From if you track MAIL FROM
reputation like I do, and start rejecting the senders that source a lot of
spam.

I will admit, my quarantine is full of a lot of messages MAIL FROM
randomlocalpart@spammerdomain.biz. So I may invent something SPF like
to protect just my own From: domains on my own servers. DKIM is too
heavyweight for that purpose.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

>>
>> There is any implementation of spf that checks the from of the data
>> transaction ?
>
> Not that is actually useful. There are valid reasons for Mail From
> and From
> to be different (look at the header of the e-mail for example).
>
>> How can i prevent forged froms on the data transaction ?
>>
>
> This is a difficult problem. SPF is only a part of the solution to
> a bigger
> problem.
>
> What MTA are you using? We might be able to suggestion specifics.



Postfix.


Thanks for your help.


-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Saturday 14 April 2007 23:59, Adrian de los Santos wrote:
> >> There is any implementation of spf that checks the from of the data
> >> transaction ?
> >
> > Not that is actually useful. There are valid reasons for Mail From
> > and From
> > to be different (look at the header of the e-mail for example).
> >
> >> How can i prevent forged froms on the data transaction ?
> >
> > This is a difficult problem. SPF is only a part of the solution to
> > a bigger
> > problem.
> >
> > What MTA are you using? We might be able to suggestion specifics.
>
> Postfix.
>
With Postfix, in order to look at body data like From, you are either needing
a content filter/smtp proxy solution or a milter. You ought to talk to
Stuart about his reputation work he mentioned. It's done in a milter that
with minimal modifications should work with Postfix 2.3 or higher.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Sat, 14 Apr 2007 17:58:20 -0400 (EDT) "Stuart D. Gathman"
<stuart@bmsi.com> wrote:
>On Sat, 14 Apr 2007, Adrian de los Santos wrote:
>
>> There is any implementation of spf that checks the from of the data
>> transaction ?
>
>No. Sender-ID could have been, but it checks some random header chosen
>by the spammer. (Well not random, but using a patented algorithm.)
>
>> How can i prevent forged froms on the data transaction ?
>
>Use DKIM. This requires the sender to sign their headers, and publish
>a public key in DNS.

Yes, except currently it lacks any way to describe in the protocol any
requirement for a relationship between the signing domain and thr From
domain. Without a reputation system behind it (Stuart this is a hint) it
is even less useful to the receiver than SPF. The DKIM working group is
chartered to deal with this, but not making a lot of progress.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote on Sunday, April 15, 2007 7:24 PM -0500:

> On Sat, 14 Apr 2007 17:58:20 -0400 (EDT) "Stuart D. Gathman"
> <stuart@bmsi.com> wrote:
> > On Sat, 14 Apr 2007, Adrian de los Santos wrote:
> >
> > > There is any implementation of spf that checks the from of the
> > > data transaction ?
> >
> > No. Sender-ID could have been, but it checks some random header
> > chosen by the spammer. (Well not random, but using a patented
> > algorithm.)
> >
> > > How can i prevent forged froms on the data transaction ?
> >
> > Use DKIM. This requires the sender to sign their headers, and
> > publish a public key in DNS.
>
> Yes, except currently it lacks any way to describe in the protocol any
> requirement for a relationship between the signing domain and thr From
> domain. Without a reputation system behind it (Stuart this is a
> hint) it is even less useful to the receiver than SPF. The DKIM
> working group is chartered to deal with this, but not making a lot of
> progress.

DKIM does validate the From: address independently, though it is
heavyweight and does not offer any information during the SMTP envelope
phase. SPF is lightweight and facilitates rejection before the SMTP
data phase, but SPF only validates MAIL FROM, not the addresses visible
to the end user. However, for the majority of ordinary email, MAIL FROM
== From:, so validating MAIL FROM with SPF also validates From:, telling
you the message is definitely not a phish with no additional overhead.
This would be noted by the MTA in some kind of trace header and the MUA
could display the fact that the message is not a phish. At such
recipients, domains that publish SPF are protected against both MAIL
FROM forgery and From: phishing.

A recipient can only conclude that MAIL FROM != From: is a phish if the
From: domain publishes the fact that they sign all mail with DKIM. If
the From: domain does not publish a DKIM policy, the recipient MTA can
only note that fact and the MUA could display the possible phish status.
In the case that the From: domain does sign all outgoing mail with DKIM
and the present message is not DKIM signed, the MTA can conclude this is
a phish and reject at the end of SMTP data. Even in this case, it is
still to a recipient's advantage to run SPF during the envelope to
reject as much junk as possible at the lowest cost, so running DKIM does
not remove the benefit of SPF.

In other words, DKIM pass/fail only buys you additional information over
SPF pass in the case where MAIL FROM != From:. If SPF would adopt a
scoping parameter (I recall Frank had op=something that said the From:
(or Sender: ?) domain must match MAIL FROM), then most domains could
protect the use of their domain name in displayed addresses without the
additional overhead of DKIM.

--
Seth Goodman

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Monday 16 April 2007 10:03, Seth Goodman wrote:

> DKIM does validate the From: address independently,

No. It does not. It may, but it does not.

The DKIM Sender Signing Policy (SSP) is not yet designed (the protocol
requirements were just finished) and it may or may not be effective for this.

Today, based on the DKIM-base RFC that has been approved there is no way to
tie signing domain to From domain (or any other header).

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote on Monday, April 16, 2007 9:13 AM -0500:

> On Monday 16 April 2007 10:03, Seth Goodman wrote:
>
> > DKIM does validate the From: address independently,
>
> No. It does not. It may, but it does not.
>
> The DKIM Sender Signing Policy (SSP) is not yet designed (the protocol
> requirements were just finished) and it may or may not be effective
> for this.
>
> Today, based on the DKIM-base RFC that has been approved there is no
> way to tie signing domain to From domain (or any other header).

Thanks for pointing this out. I'll have to look at the current RFC.
Any authentication protocol that is optional only works if the recipient
can query the sender's policy out-of-band (not in the message). If the
only information the recipient has is what's presented in the DKIM
signature header, they can only trust it if the domain that supplies the
public key is the same as the sender domain, whatever you consider that
to be. How does DKIM currently deal with combinations of From:,
Sender:, Resent-*: addresses to determine sender domain?

In any case, I think my point about MAILFROM: == From: for the majority
of legitimate messages still holds. SPF pass also validates From: when
it uses the same domain (well, really PRA, not strictly From:). Unlike
DKIM + DKIM sender signing policy (I assume they will get there), SPF
pass tells you nothing about From: when different than MAILFROM:.
However, adding scope to SPF, either directly or via op= modifier, is a
*much* lighter weight method for both senders and recipients to
accomplish the same thing.

--
Seth Goodman

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote:
> On Sat, 14 Apr 2007 17:58:20 -0400 (EDT) "Stuart D. Gathman"
> <stuart@bmsi.com> wrote:
>
>> On Sat, 14 Apr 2007, Adrian de los Santos wrote:
>>
>>
>>> There is any implementation of spf that checks the from of the data
>>> transaction ?
>>>
>> No. Sender-ID could have been, but it checks some random header chosen
>> by the spammer. (Well not random, but using a patented algorithm.)
>>
>>
>>> How can i prevent forged froms on the data transaction ?
>>>
>> Use DKIM. This requires the sender to sign their headers, and publish
>> a public key in DNS.
>>
>
> Yes, except currently it lacks any way to describe in the protocol any
> requirement for a relationship between the signing domain and thr From
> domain. Without a reputation system behind it (Stuart this is a hint) it
> is even less useful to the receiver than SPF. The DKIM working group is
> chartered to deal with this, but not making a lot of progress.
>

The DKIM working group just completed last-call on the requirements
document for SSP, and that seems like a fair bit of progress to me.

-Jim

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

Not trying to turn this into dkim-discuss, but...

Scott Kitterman wrote:
> On Monday 16 April 2007 10:03, Seth Goodman wrote:
>
>
>> DKIM does validate the From: address independently,
>>
>
> No. It does not. It may, but it does not.
>
> The DKIM Sender Signing Policy (SSP) is not yet designed (the protocol
> requirements were just finished) and it may or may not be effective for this.
>
> Today, based on the DKIM-base RFC that has been approved there is no way to
> tie signing domain to From domain (or any other header).
>

The DKIM -base specification does not mandate that a signature be tied
to the From domain, so that other entities (like mailing lists) can sign
messages. However, it is certainly possible for a verifier to determine
if a signature is tied to the From address, and the verifier can act
upon this fact, even in the absence of SSP.

-Jim

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Tuesday 17 April 2007 23:43, Jim Fenton wrote:
> Scott Kitterman wrote:
> > On Sat, 14 Apr 2007 17:58:20 -0400 (EDT) "Stuart D. Gathman"
> >
> > <stuart@bmsi.com> wrote:
> >> On Sat, 14 Apr 2007, Adrian de los Santos wrote:
> >>> There is any implementation of spf that checks the from of the data
> >>> transaction ?
> >>
> >> No. Sender-ID could have been, but it checks some random header chosen
> >> by the spammer. (Well not random, but using a patented algorithm.)
> >>
> >>> How can i prevent forged froms on the data transaction ?
> >>
> >> Use DKIM. This requires the sender to sign their headers, and publish
> >> a public key in DNS.
> >
> > Yes, except currently it lacks any way to describe in the protocol any
> > requirement for a relationship between the signing domain and thr From
> > domain. Without a reputation system behind it (Stuart this is a hint) it
> > is even less useful to the receiver than SPF. The DKIM working group is
> > chartered to deal with this, but not making a lot of progress.
>
> The DKIM working group just completed last-call on the requirements
> document for SSP, and that seems like a fair bit of progress to me.
>
Hello Jim,

Welcome.

You are correct about the last-call. Personally, I'm very pessimistic that
the group will produce anything useful. I haven't given up. We'll see.

But none of that's useful for admins who need something they can deploy today.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

After 4 days of my original question (how to prevent phising that
uses fake From information) and reading all the answers and doing my
own research, i can say that:


- There is no working tool that prevents or authenticates internet
mail (domain keys, spf, sender-id, etc.)

- There is nothing useful commercial or open source that prevents
phishing

- The problem it's not in the tools, the protocol itself SMTP was
never designed to prevent this from happening and the protocol itself
needs to be redone, it was good 10+ years ago, now it just look silly
that anyone can forge an email message and there is no real way to
prevent it. Instead of wasting time and effort trying to solve
problems created by the protocol why not redesign the protocol ???
who is doing that ???


Thanks for your comments..





-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Thursday 19 April 2007 23:42, Adrian de los Santos wrote:
> After 4 days of my original question (how to prevent phising that
> uses fake From information) and reading all the answers and doing my
> own research, i can say that:
>
>
> - There is no working tool that prevents or authenticates internet
> mail (domain keys, spf, sender-id, etc.)

This is true. SPF is a piece of the puzzle. DK/DKIM has potential to be
another significant piece, but until their (I'm part of the DKIM WG) policy
protocol work is done and the reliability of the cryptographic protocol is
established in Internet scale use, it's premature to say. Sender-ID does an
excellent job of protecting the resent-sender header. If that's important to
anyone, they should do Sender-ID.

> - There is nothing useful commercial or open source that prevents
> phishing

No, but I think we are getting close. I think that Stuart's discussion about
combinging reputation with SPF is a strong point in the correct direction.
I've been involved in some other, similar research work that is promising
(just research at this point, no product yet).

> - The problem it's not in the tools, the protocol itself SMTP was
> never designed to prevent this from happening and the protocol itself
> needs to be redone, it was good 10+ years ago, now it just look silly
> that anyone can forge an email message and there is no real way to
> prevent it. Instead of wasting time and effort trying to solve
> problems created by the protocol why not redesign the protocol ???
> who is doing that ???

That has been proposed. In my opionion there is too much momentum behind SMTP
to stop and redesign it. If this does happen it's going to be some other
non-email protocol that just eats smtp's lunch. Maybe some kind of
RSS/Jabber something. I don't know.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Fri, 20 Apr 2007, Scott Kitterman wrote:

> No, but I think we are getting close. I think that Stuart's discussion about
> combinging reputation with SPF is a strong point in the correct direction.

I have a working product based on sendmail, pymilter, pysrs, pyspf, pygossip,
pydspam. It is all config file based (no web UI), but very effective.
http://pymilter.sf.net

> That has been proposed. In my opionion there is too much momentum behind
> SMTP to stop and redesign it. If this does happen it's going to be some
> other non-email protocol that just eats smtp's lunch. Maybe some kind of
> RSS/Jabber something. I don't know.

My money is on Jabber. But you'll still need a reputation system for
jabber domains. You'll notice that widely used IM systems have some
sort of reputation. For instance, AIM provides "Warn" and "Block" buttons.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote on Friday, April 20, 2007 11:19 AM -0500:

> On Fri, 20 Apr 2007, Scott Kitterman wrote:
>
> > That has been proposed. In my opionion there is too much momentum
> > behind SMTP to stop and redesign it. If this does happen it's
> > going to be some other non-email protocol that just eats smtp's
> > lunch. Maybe some kind of RSS/Jabber something. I don't know.
>
> My money is on Jabber. But you'll still need a reputation system for
> jabber domains. You'll notice that widely used IM systems have some
> sort of reputation. For instance, AIM provides "Warn" and "Block"
> buttons.

The issue is not whether there is a reputation system, but whether you
have a verifiable identity to look up. SMTP was designed when there was
no reason to distrust an identity, and it also had to accommodate relay
transfers since the internet wasn't yet fully interconnected. The
multiple identities inherent in a multi-hop transfer, coupled with the
inconsistent recording of transit information (Received: headers are
optional trace headers), made the task of validating identities very
difficult. Add to that the complete generality of the multiple sender
identities in SMTP, which need not bear any relation to one another, and
the situation for recipients is difficult.

The IM protocols all came about after the appearance of email spam and
after the internet became fully interconnected, so they naturally did a
better job of controlling sender identities. PGP, S/MIME, SPF and DKIM
are all ancillary protocols to add some measure of sender identity
verification to SMTP. The fact that no ancillary protocol has
succeeded, despite the problem getting worse, is evidence that a major
change to SMTP for this purpose is most likely impossible at this point.

--
Seth Goodman

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Fri, 20 Apr 2007, Seth Goodman wrote:

> Stuart D. Gathman wrote on Friday, April 20, 2007 11:19 AM -0500:
>
>> On Fri, 20 Apr 2007, Scott Kitterman wrote:
>>
>>> That has been proposed. In my opionion there is too much momentum
>>> behind SMTP to stop and redesign it. If this does happen it's
>>> going to be some other non-email protocol that just eats smtp's
>>> lunch. Maybe some kind of RSS/Jabber something. I don't know.
>>
>> My money is on Jabber. But you'll still need a reputation system for
>> jabber domains. You'll notice that widely used IM systems have some
>> sort of reputation. For instance, AIM provides "Warn" and "Block"
>> buttons.
>
> The issue is not whether there is a reputation system, but whether you
> have a verifiable identity to look up. SMTP was designed when there was
> no reason to distrust an identity, and it also had to accommodate relay
> transfers since the internet wasn't yet fully interconnected. The
> multiple identities inherent in a multi-hop transfer, coupled with the
> inconsistent recording of transit information (Received: headers are
> optional trace headers), made the task of validating identities very
> difficult. Add to that the complete generality of the multiple sender
> identities in SMTP, which need not bear any relation to one another, and
> the situation for recipients is difficult.
>
> The IM protocols all came about after the appearance of email spam and
> after the internet became fully interconnected, so they naturally did a
> better job of controlling sender identities. PGP, S/MIME, SPF and DKIM
> are all ancillary protocols to add some measure of sender identity
> verification to SMTP. The fact that no ancillary protocol has
> succeeded, despite the problem getting worse, is evidence that a major
> change to SMTP for this purpose is most likely impossible at this point.

Not necessarily. Patching is more difficult to achieve good structure
that everyone is cormtable with then when the core contains needed
features. I thought back in 2002 that SMTP needs redesign but multiple
people tried to convince me that its not true and that it can be
extended to fix those problems. Ok, they are probably right that it can
in theory be extended, but I no longer see it as practicly achieveable.

So if people are interested in SMTPng, I'm all for trying to go at it again.

--
William Leibzon
Elan Networks
william@elan.net

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com