Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SPF: Discuss

SPF, DKIM, and NIH

 

 

First page Previous page 1 2 3 Next page Last page  View All SPF discuss RSS feed   Index | Next | Previous | View Threaded


scott at kitterman

Oct 12, 2009, 9:21 AM

Post #26 of 63 (2655 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Mon, 12 Oct 2009 09:14:22 -0700 (PDT) Michael Deutschmann
<michael [at] talamasca> wrote:
>On Mon, 12 Oct 2009, Scott Kitterman wrote:
>> OK, then what is the sender signing?
>
>The signature will lock down the same things as in DKIM/ADSP -- the
>entire body and the sender's choice of headers. Only the d= values of the
>signatures of interest to the validator will be different.
>
>Not that it matters. Traditional forwarders send the message verbatim, so
>they don't need to care. Mailing lists can freely break the original
>envelope-signature since they do not assert the original envelope.

So I still need to accept the message body to determine if it passed?

For the 80 percent of mail that has the same mail from and from domain,
what would be the difference between this and a standard first party DKIM
signature?

For the remainder, what would be the difference between this and a standard
3rd party signature?

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


stuart at bmsi

Oct 12, 2009, 9:37 AM

Post #27 of 63 (2652 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Mon, 12 Oct 2009, Ian Eiloart wrote:

> > Then what's the advantge over SPF?
>
> The advantage is that it permits trusted traditional forwarding. Which is
> what's missing with SPF.

SPF provides trusted traditional forwarding with a little extra work
on the sender side to provide a custom DNS backend.

--
Stuart D. Gathman <stuart [at] bmsi>
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
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


michael at talamasca

Oct 12, 2009, 10:05 AM

Post #28 of 63 (2653 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Mon, 12 Oct 2009, Scott Kitterman wrote:
> So I still need to accept the message body to determine if it passed?

Sometimes. Here's the matrix:

SPF EDSP Forwarder Action
---- ---- --------- ------
(any) (any) Yes Accept message
Pass (any) (any) Accept message
Neutral No (any) Accept message
Neutral Yes No Let pass RCPT, accept if signed
Neutral Yes Maybe Let pass RCPT, accept if signed
Fail (any) No Reject at RCPT
Fail No Maybe Accept message (grudgingly...)
Fail Yes Maybe Let pass RCPT, accept if signed

SPF none and softdeny are treated same as neutral. The forwarder column
refers to any other intelligence the recipient has as to whether the
message is from a legitimate forwarder.

EDSP refers to whether the MAIL FROM domain has posted an envelope-dkim
signing policy -- not the presence of a signature, which you don't know
yet.

> For the 80 percent of mail that has the same mail from and from domain,
> what would be the difference between this and a standard first party DKIM
> signature?
No difference. In fact, since the required d= value for DKIM/ADSP and
Envelope DKIM in this case are identical, the deployment of Envelope DKIM
at a DKIM/ADSP would not change a byte of outgoing messages in this class.

The main advatange of Envelope DKIM is that it protects you from being
suckered into accepting a message on probation because of a DKIM/ADSP
policy on the MAIL FROM: address, only to find that the header From: is
something completely different.

> For the remainder, what would be the difference between this and a standard
> 3rd party signature?
There's no such thing as a "standard 3rd party signature" at present.
Envelope DKIM might become the first.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


scott at kitterman

Oct 12, 2009, 11:47 AM

Post #29 of 63 (2654 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Mon, 12 Oct 2009 12:20:07 -0400 (EDT) "Stuart D. Gathman"
<stuart [at] bmsi> wrote:
>On Mon, 12 Oct 2009, Scott Kitterman wrote:
>
>> >Without giving up SPF's mailing list FP immunity, it gains the same
>> >forwarding FP immunity DKIM/ADSP has.
>> >
>> >
>> >It would work smoother than a mere "reject mail only if DKIM/ADSP and
SPF
>> >both say Fail" policy, because the mailserver would know in advance
>> >whether it is worthwhile to let an incoming SPF-fail transaction proceed
>> >to DATA.
>> >
>> OK, then what is the sender signing?
>
>The sender is signing MAIL FROM in a manner similar to SES. SES would
>actually be a more efficient way to accomplish the same goal, be
>evaluated at SMTP envelope time, and works with the existing SPF standard
>(via exists mechanism).
>
>The drawback? It requires the sender to supply a specialized backend to a DNS
>server to handle the validation requests. (PowerDNS is an authoritative only
>open source DNS server that makes plug-in backends easy - so this is not a
>showstopper.)
>
>On the other hand, the DKIMed MAIL FROM proposal puts the burden of
>special software on the receiver.

Also in SES, the 'signature' is encoded in the mail from. With this DKIM
envolope idea there is nothing to sign, but the body and the body header.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


scott at kitterman

Oct 12, 2009, 11:53 AM

Post #30 of 63 (2655 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Mon, 12 Oct 2009 10:05:24 -0700 (PDT) Michael Deutschmann
<michael [at] talamasca> wrote:
>On Mon, 12 Oct 2009, Scott Kitterman wrote:
>> So I still need to accept the message body to determine if it passed?
>
>Sometimes. Here's the matrix:
>
>SPF EDSP Forwarder Action
>---- ---- --------- ------
>(any) (any) Yes Accept message
>Pass (any) (any) Accept message
>Neutral No (any) Accept message
>Neutral Yes No Let pass RCPT, accept if signed
>Neutral Yes Maybe Let pass RCPT, accept if signed
>Fail (any) No Reject at RCPT
>Fail No Maybe Accept message (grudgingly...)
>Fail Yes Maybe Let pass RCPT, accept if signed
>
>SPF none and softdeny are treated same as neutral. The forwarder column
>refers to any other intelligence the recipient has as to whether the
>message is from a legitimate forwarder.
>
>EDSP refers to whether the MAIL FROM domain has posted an envelope-dkim
>signing policy -- not the presence of a signature, which you don't know
>yet.
>
>> For the 80 percent of mail that has the same mail from and from domain,
>> what would be the difference between this and a standard first party
DKIM
>> signature?
>No difference. In fact, since the required d= value for DKIM/ADSP and
>Envelope DKIM in this case are identical, the deployment of Envelope DKIM
>at a DKIM/ADSP would not change a byte of outgoing messages in this class.
>
>The main advatange of Envelope DKIM is that it protects you from being
>suckered into accepting a message on probation because of a DKIM/ADSP
>policy on the MAIL FROM: address, only to find that the header From: is
>something completely different.
>
>> For the remainder, what would be the difference between this and a
standard
>> 3rd party signature?
>There's no such thing as a "standard 3rd party signature" at present.
>Envelope DKIM might become the first.

This is where I think you go astray. DKIM has no requirement for the "d"
domain and the body from domain to match. So really all you are saying is
check if the domain used in mail from has a DKIM key record? If so, that's
a problem because you need to go to DATA to get the signature to find out
what the selector is.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


michael at talamasca

Oct 12, 2009, 5:44 PM

Post #31 of 63 (2652 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Mon, 12 Oct 2009, Scott Kitterman wrote:
> This is where I think you go astray. DKIM has no requirement for the "d"
> domain and the body from domain to match. So really all you are saying is

DKIM doesn't. DKIM/ADSP does, although signatures with "wrong" d= are
ignored rather than considered errors -- a fact my proposal counts on.

DKIM was built to allow for third-party signatures, but at present there is
no standard way to indicate that signatures other than that for the From:
domain *are required*. That's what I want to fix.

> check if the domain used in mail from has a DKIM key record? If so, that's
> a problem because you need to go to DATA to get the signature to find out
> what the selector is.

No, at MAIL FROM: time you check whether the SPF record has a flag
indicating an envelope signing policy (such as my "fm=dkim" suggestion).
If the flag is set, you know, before seeing the DATA yourself, that either
the message will have a valid signature with d= matching the Return-path:,
or it is forged.

The test is more expensive than SPF, but when supported it is more accurate,
since it is as immune as DKIM/ADSP to the forwarder problem.


And remember, if SPF returns fail *and* you are sure the message is
not a forward, you are still allowed to reject the message without ever
looking at the DATA.

---- Michael Deutschmann <michael [at] talamasca>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 13, 2009, 1:53 AM

Post #32 of 63 (2653 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 12 October 2009 12:37:30 -0400 "Stuart D. Gathman" <stuart [at] bmsi>
wrote:

> On Mon, 12 Oct 2009, Ian Eiloart wrote:
>
>> > Then what's the advantge over SPF?
>>
>> The advantage is that it permits trusted traditional forwarding. Which is
>> what's missing with SPF.
>
> SPF provides trusted traditional forwarding with a little extra work
> on the sender side to provide a custom DNS backend.

I should elaborate, perhaps I mis-phrased that. If you sign with DKIM, you
don't need to know whether your recipient is using traditional forwarding.
There's no work for you or the forwarder to do. It means that the recipient
can determine the origin of a traditionally forwarded email.

With SPF, you can of course allow trusted third parties to forward email
for you.


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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


vesely at tana

Oct 13, 2009, 4:39 AM

Post #33 of 63 (2650 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

David MacQuigg wrote:
> Ian Eiloart wrote:
>> If SPF fails, then look for a DKIM signature. If you get a good one,
>> you're likely seeing traditional forwarding.
>
> Or forwarding by a crook. What prevents a spammer from sending a
> billion ads for Viagra, all with a valid DKIM signature from a reputable
> domain? All it takes is one signed message. The rest can be copies,
> "forwarded" via a botnet.
>
> The fundamental advantage of signature-based authentication (arbitrary
> forwarding) is a fundamental disadvantage when the forwarder is a
> crook. Signatures protect only that which is signed, i.e. the body and
> a few specifically selected headers. There is *no other assurance* in a
> signature. Show that Viagra ad to the original signer, and he will say
> "Yup, that's our signature. We sign 500,000 messages per day. We have
> per-account rate limits. We even run spam filters on new accounts.
> What else do you expect us to do? "

Nice one, David! I've tried to convert it into a shorter version in
http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Arbitrary_forwarding



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 13, 2009, 5:01 AM

Post #34 of 63 (2656 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 13 October 2009 13:39:44 +0200 Alessandro Vesely <vesely [at] tana>
wrote:

> David MacQuigg wrote:
>> Ian Eiloart wrote:
>>> If SPF fails, then look for a DKIM signature. If you get a good one,
>>> you're likely seeing traditional forwarding.
>>
>> Or forwarding by a crook. What prevents a spammer from sending a
>> billion ads for Viagra, all with a valid DKIM signature from a reputable
>> domain? All it takes is one signed message. The rest can be copies,
>> "forwarded" via a botnet.

Nothing prevents that, but the only purpose it would serve would be to harm
the reputation of the original signer, or to increase the income of the
original signer. The spammer could derive no benefit, since the advert
would not route the buyer through the spammer's reward system.

Now, let's get more specific. Suppose the original message were sent from a
gmail account set up for the purpose. You're proposing this mechanism to
route around rate-limiting, or other bulk mail detectors on the gmail
server. That's fine, it'll do that. And who's reputation suffers? Not
gmail's, but the sender address. With a sufficiently responsive reputation
infrastructure, the sender address will quickly acquire poor reputation.

Nobody would be daft enough to assign anything but neutral reputation to
the gmail.com domain, would they?

>> The fundamental advantage of signature-based authentication (arbitrary
>> forwarding) is a fundamental disadvantage when the forwarder is a
>> crook. Signatures protect only that which is signed, i.e. the body and
>> a few specifically selected headers. There is *no other assurance* in a
>> signature. Show that Viagra ad to the original signer, and he will say
>> "Yup, that's our signature. We sign 500,000 messages per day. We have
>> per-account rate limits. We even run spam filters on new accounts.
>> What else do you expect us to do? "
>
> Nice one, David! I've tried to convert it into a shorter version in
> http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Arbitrary_forward
> ing
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com



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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


stuart at bmsi

Oct 13, 2009, 5:41 AM

Post #35 of 63 (2652 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Tue, 13 Oct 2009, Ian Eiloart wrote:

> Nobody would be daft enough to assign anything but neutral reputation to the
> gmail.com domain, would they?

While gmail.com has so far managed to keep spammers under enough control
to avoid a seriously bad reputation on my system, other free email domains,
like comcast, have reputations so bad they are rejected outright by default.
Individual senders can be whitelisted. This is not daft. If they were
not rejected outright by default, the quarantine would be so full of
crap, the rare false positive from content filtering would have even
less chance of being noticed.

One strategy I'm considering is to start rejecting content filtered
email (at end of message) instead of quarantining it for a domain with bad
reputation. This would at least give the occasional legit sender at comcast a
chance to have their mail delivered, would still avoid too much quarantined
junk, and a rejected legit sender would get a 5xx just like now.

--
Stuart D. Gathman <stuart [at] bmsi>
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
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 13, 2009, 6:15 AM

Post #36 of 63 (2648 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 13 October 2009 08:41:54 -0400 "Stuart D. Gathman" <stuart [at] bmsi>
wrote:

> On Tue, 13 Oct 2009, Ian Eiloart wrote:
>
>> Nobody would be daft enough to assign anything but neutral reputation to
>> the gmail.com domain, would they?
>
> While gmail.com has so far managed to keep spammers under enough control
> to avoid a seriously bad reputation on my system, other free email

Right, but you wouldn't given them a positive reputatation score would you?
Say, to reduce spamassassin score on the domain name (+DKIM verification)
alone?

> domains, like comcast, have reputations so bad they are rejected outright
> by default. Individual senders can be whitelisted. This is not daft. If
> they were not rejected outright by default, the quarantine would be so
> full of crap, the rare false positive from content filtering would have
> even less chance of being noticed.




> One strategy I'm considering is to start rejecting content filtered
> email (at end of message)

We do that. We don't quarantine anything: if we don't like it, we reject it
at smtp time, otherwise we deliver it with spamassassin comments added, so
that users can filter if they wish. Above a certain threshold, though, we
simply reject.

> instead of quarantining it for a domain with bad
> reputation. This would at least give the occasional legit sender at
> comcast a chance to have their mail delivered, would still avoid too much
> quarantined junk, and a rejected legit sender would get a 5xx just like
> now.



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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


macquigg at ece

Oct 13, 2009, 10:25 AM

Post #37 of 63 (2650 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

Ian Eiloart wrote:
> --On 13 October 2009 13:39:44 +0200 Alessandro Vesely <vesely [at] tana>
> wrote:
>> David MacQuigg wrote:
>>> Ian Eiloart wrote:
>>>> If SPF fails, then look for a DKIM signature. If you get a good one,
>>>> you're likely seeing traditional forwarding.
>>>
>>> Or forwarding by a crook. What prevents a spammer from sending a
>>> billion ads for Viagra, all with a valid DKIM signature from a
>>> reputable
>>> domain? All it takes is one signed message. The rest can be copies,
>>> "forwarded" via a botnet.
>
> Nothing prevents that, but the only purpose it would serve would be to
> harm the reputation of the original signer, or to increase the income
> of the original signer. The spammer could derive no benefit, since the
> advert would not route the buyer through the spammer's reward system.

Most of the spam hitting my receiver at box67.com does not depend on a
reply to a verified address. The spammer or phisher benefits when you
click on a link, or buy a stock, or change your thinking on a political
issue.

As for the reputation of the original signer, it won't suffer much.
Most receivers have enough common sense to not blame Yahoo for one spam
slipping past their filters. Lowering Yahoo's reputation would only
harm the receiver's filtering process.

> Now, let's get more specific. Suppose the original message were sent
> from a gmail account set up for the purpose. You're proposing this
> mechanism to route around rate-limiting, or other bulk mail detectors
> on the gmail server. That's fine, it'll do that. And who's reputation
> suffers? Not gmail's, but the sender address. With a sufficiently
> responsive reputation infrastructure, the sender address will quickly
> acquire poor reputation.

Most spam is transmitted by zombies in a botnet. Gmail is an
exception. Their reputation is suffering, because the spam is coming
directly from their authorized transmitters.

> Nobody would be daft enough to assign anything but neutral reputation
> to the gmail.com domain, would they?

The domain associate with their transmitters is actually google.com, and
our rating has varied from B to C. C is "unknown" or "neutral" to use
your terminology. We have never assigned a rating lower than C, because
spammers never stick with one name long enough to acquire a "bad"
reputation.

-- Dave



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


stuart at bmsi

Oct 13, 2009, 12:40 PM

Post #38 of 63 (2650 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Tue, 13 Oct 2009, Ian Eiloart wrote:

> > While gmail.com has so far managed to keep spammers under enough control
> > to avoid a seriously bad reputation on my system, other free email
>
> Right, but you wouldn't given them a positive reputatation score would you?
> Say, to reduce spamassassin score on the domain name (+DKIM verification)
> alone?

*I* don't assign any reputation scores. The system tracks the last 1024
emails from each (domain,SPF Result) pair and reputation is a function
of the spam/ham ratio and the length of time the domain has been
known. The reputation is objective - only the classification of
messages into spam/ham is subjective. (E.g., one customer, a travel agent,
considers travel spam "must reading".)

At the moment, gmail.com in fact has a positive score on +31 on a scale
of -100,+100 with confidence of 83 on a scale of 0,100. So despite
the constant robot abuse, they still send us more ham than spam. I.e.,
they are at least keeping the robots at bay.

--
Stuart D. Gathman <stuart [at] bmsi>
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 [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


stuart at bmsi

Oct 13, 2009, 2:13 PM

Post #39 of 63 (2661 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Tue, 13 Oct 2009, Ian Eiloart wrote:

> > > The advantage is that it permits trusted traditional forwarding. Which is
> > > what's missing with SPF.
> >
> > SPF provides trusted traditional forwarding with a little extra work
> > on the sender side to provide a custom DNS backend.
>
> I should elaborate, perhaps I mis-phrased that. If you sign with DKIM, you
> don't need to know whether your recipient is using traditional forwarding.
> There's no work for you or the forwarder to do. It means that the recipient
> can determine the origin of a traditionally forwarded email.
>
> With SPF, you can of course allow trusted third parties to forward email for
> you.

With the exists mechanism, you can "sign" the MAIL FROM and allow traditional
forwarding without knowing anything about the recipients.
The exists mechanism queries your custom DNS as to whether the signature
is valid. It can be algorithm based, or a random string in a database.
This is known as "SES" Signed Envelope Sender. It works seamlessly with
SPF and with traditional forwarders from the standpoint of the recipient.
The sender has to set up the custom DNS to respond to the exists queries.
Typically, the exists would be the final mechanism before -all to avoid
the extra query in cases where the mail is not traditionally forwarded.

For instance:

example.com IN TXT "v=spf1 mx exists:%{l}.ses.example.com -all"

And the ses.example.com zone is server by PowerDNS or other DNS server
with pluggable backends. The MAIL FROM might look something like (using my SES
package):

SES=GSVRXAGC8F16O1BTE=john [at] example

Though of course, the format is entirely arbitrary since it is validated
only by the sender.

Now that doesn't mean DKIM is useless. SES doesn't include the body,
so the signature involves a timestamp and/or sequence number. This
has to change infrequently enough that it won't prevent a recipients
greylisting system from working, or else you have to store the MAIL FROM
in the queued message to be reused on retries (easier now that the milter
API includes CHGFROM).

The advantange of DKIM for envelope signing is that it includes the body.
The disadvantage of DKIM for envelope signing is that it includes the body.

--
Stuart D. Gathman <stuart [at] bmsi>
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 [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 14, 2009, 4:36 AM

Post #40 of 63 (2649 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 13 October 2009 10:25:15 -0700 David MacQuigg
<macquigg [at] ece> wrote:

> Ian Eiloart wrote:
>> --On 13 October 2009 13:39:44 +0200 Alessandro Vesely <vesely [at] tana>
>> wrote:
>>> David MacQuigg wrote:
>>>> Ian Eiloart wrote:
>>>>> If SPF fails, then look for a DKIM signature. If you get a good one,
>>>>> you're likely seeing traditional forwarding.
>>>>
>>>> Or forwarding by a crook. What prevents a spammer from sending a
>>>> billion ads for Viagra, all with a valid DKIM signature from a
>>>> reputable
>>>> domain? All it takes is one signed message. The rest can be copies,
>>>> "forwarded" via a botnet.
>>
>> Nothing prevents that, but the only purpose it would serve would be to
>> harm the reputation of the original signer, or to increase the income
>> of the original signer. The spammer could derive no benefit, since the
>> advert would not route the buyer through the spammer's reward system.
>
> Most of the spam hitting my receiver at box67.com does not depend on a
> reply to a verified address. The spammer or phisher benefits when you
> click on a link, or buy a stock, or change your thinking on a political
> issue.

That's not relevant. The message is still from the original sender, and
still benefits the original sender, because the body of the message is
signed.

> As for the reputation of the original signer, it won't suffer much. Most
> receivers have enough common sense to not blame Yahoo for one spam
> slipping past their filters. Lowering Yahoo's reputation would only harm
> the receiver's filtering process.

That's a good point. For large ESPs, you have to do the reputation
assignment by some part of the signed content of the message, perhaps the
From address. But, the DKIM signature allows you to do that for addresses
in the signing domain.

>> Now, let's get more specific. Suppose the original message were sent
>> from a gmail account set up for the purpose. You're proposing this
>> mechanism to route around rate-limiting, or other bulk mail detectors
>> on the gmail server. That's fine, it'll do that. And who's reputation
>> suffers? Not gmail's, but the sender address. With a sufficiently
>> responsive reputation infrastructure, the sender address will quickly
>> acquire poor reputation.
>
> Most spam is transmitted by zombies in a botnet. Gmail is an exception.
> Their reputation is suffering, because the spam is coming directly from
> their authorized transmitters.

Yep. Botnets can be reasonably deal with using IP reputation assignment.
That's not true for the large ESPs, because the IP addresses are shared
with good and bad senders. Similarly for large ESP domains.

>> Nobody would be daft enough to assign anything but neutral reputation
>> to the gmail.com domain, would they?
>
> The domain associate with their transmitters is actually google.com, and
> our rating has varied from B to C. C is "unknown" or "neutral" to use
> your terminology. We have never assigned a rating lower than C, because
> spammers never stick with one name long enough to acquire a "bad"
> reputation.
>
> -- Dave
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com



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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


vesely at tana

Oct 14, 2009, 11:35 AM

Post #41 of 63 (2657 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

Ian Eiloart wrote:
>> One strategy I'm considering is to start rejecting content filtered
>> email (at end of message)
>
> We do that. We don't quarantine anything: if we don't like it, we reject
> it at smtp time, otherwise we deliver it with spamassassin comments
> added, so that users can filter if they wish. Above a certain threshold,
> though, we simply reject.

The common criterion for dropping is that by rejecting you are
providing a free test machine for spammers to keep trying various
alternatives until they get the message through. (Well, transferring
SA comments to a multi-line rejection text isn't usually provided.)



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


spfdiscuss at alandoherty

Oct 14, 2009, 11:59 AM

Post #42 of 63 (2648 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

At 19:35 14/10/2009 Wednesday, Alessandro Vesely wrote:
>Ian Eiloart wrote:
>>>One strategy I'm considering is to start rejecting content filtered
>>>email (at end of message)
>>We do that. We don't quarantine anything: if we don't like it, we reject it at smtp time, otherwise we deliver it with spamassassin comments added, so that users can filter if they wish. Above a certain threshold, though, we simply reject.
>
>The common criterion for dropping is that by rejecting you are providing a free test machine for spammers to keep trying various alternatives until they get the message through. (Well, transferring SA comments to a multi-line rejection text isn't usually provided.)

the opposing view is of course by rejecting the spammer usually dosn't profit
accepted messages {even if spamfoldered or quarantined} are still counted as deliveries and thus result in profit

also rejections from false-positives give the sender an opportunity for response, out of band contact for whitelisting, or other remediation
accept>dump gives no way for sender or recipient to detect and remedy false positives



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


macquigg at ece

Oct 14, 2009, 3:08 PM

Post #43 of 63 (2649 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

Ian Eiloart wrote:
> --On 13 October 2009 10:25:15 -0700 David MacQuigg
> <macquigg [at] ece> wrote:
>> Ian Eiloart wrote:
>>> --On 13 October 2009 13:39:44 +0200 Alessandro Vesely <vesely [at] tana>
>>> wrote:
>>>> David MacQuigg wrote:
>>>>> Ian Eiloart wrote:
>>>>>> If SPF fails, then look for a DKIM signature. If you get a good one,
>>>>>> you're likely seeing traditional forwarding.
>>>>>
>>>>> Or forwarding by a crook. What prevents a spammer from sending a
>>>>> billion ads for Viagra, all with a valid DKIM signature from a
>>>>> reputable
>>>>> domain? All it takes is one signed message. The rest can be copies,
>>>>> "forwarded" via a botnet.
>>>
>>> Nothing prevents that, but the only purpose it would serve would be to
>>> harm the reputation of the original signer, or to increase the income
>>> of the original signer. The spammer could derive no benefit, since the
>>> advert would not route the buyer through the spammer's reward system.
>>
>> Most of the spam hitting my receiver at box67.com does not depend on a
>> reply to a verified address. The spammer or phisher benefits when you
>> click on a link, or buy a stock, or change your thinking on a political
>> issue.
>
> That's not relevant. The message is still from the original sender,
> and still benefits the original sender, because the body of the
> message is signed.

If a spammer gets a free account at Yahoo, and sends himself an ad for
Viagra, an ad with a link to a phony website that does nothing but
collect credit numbers, how does Yahoo benefit?

Let's try to avoid ambiguous words like "sender". In this case, we have
an author (the spammer) and a signer (Yahoo). Clearly the author
benefits in getting a DKIM signature from a reputable domain, but how
does Yahoo benefit?

>> As for the reputation of the original signer, it won't suffer much.
>> Most
>> receivers have enough common sense to not blame Yahoo for one spam
>> slipping past their filters. Lowering Yahoo's reputation would only
>> harm
>> the receiver's filtering process.
>
> That's a good point. For large ESPs, you have to do the reputation
> assignment by some part of the signed content of the message, perhaps
> the From address. But, the DKIM signature allows you to do that for
> addresses in the signing domain.

These addresses are worthless. You can get 1000 free accounts for less
than a penny each ($2 to break 1000 CrAPTCHAs). http://decaptcher.com

>>> Now, let's get more specific. Suppose the original message were sent
>>> from a gmail account set up for the purpose. You're proposing this
>>> mechanism to route around rate-limiting, or other bulk mail detectors
>>> on the gmail server. That's fine, it'll do that. And who's reputation
>>> suffers? Not gmail's, but the sender address. With a sufficiently
>>> responsive reputation infrastructure, the sender address will quickly
>>> acquire poor reputation.

OK, I think I understand now what you mean by "sender". Sender
(individual author) addresses are worthless to identify bad senders.
See above.

>> Most spam is transmitted by zombies in a botnet. Gmail is an exception.
>> Their reputation is suffering, because the spam is coming directly from
>> their authorized transmitters.
>
> Yep. Botnets can be reasonably deal with using IP reputation
> assignment. That's not true for the large ESPs, because the IP
> addresses are shared with good and bad senders. Similarly for large
> ESP domains.

???

-- Dave



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


vesely at tana

Oct 15, 2009, 11:27 PM

Post #44 of 63 (2646 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

alan wrote:
>> The common criterion for dropping is that by rejecting you are providing a free test machine for spammers to keep trying various alternatives until they get the message through. (Well, transferring SA comments to a multi-line rejection text isn't usually provided.)
>
> the opposing view is of course by rejecting the spammer usually dosn't profit
> accepted messages {even if spamfoldered or quarantined} are still counted as deliveries and thus result in profit

People can resort to creative accounting by various means.
Insincerity is also implied in the oleaginous hypocrisy of using the
term /quarantine/, as if messages were bound to be reconsidered
after some time...

> also rejections from false-positives give the sender an opportunity for response, out of band contact for whitelisting, or other remediation
> accept>dump gives no way for sender or recipient to detect and remedy false positives

They can routinely ask for disposition notifications, auto-whitelist
email addresses, and similar palliatives. Of course, spam does
worsen mail reliability.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 16, 2009, 2:17 AM

Post #45 of 63 (2647 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 14 October 2009 20:35:16 +0200 Alessandro Vesely <vesely [at] tana>
wrote:

> Ian Eiloart wrote:
>>> One strategy I'm considering is to start rejecting content filtered
>>> email (at end of message)
>>
>> We do that. We don't quarantine anything: if we don't like it, we reject
>> it at smtp time, otherwise we deliver it with spamassassin comments
>> added, so that users can filter if they wish. Above a certain threshold,
>> though, we simply reject.
>
> The common criterion for dropping is that by rejecting you are providing
> a free test machine for spammers to keep trying various alternatives
> until they get the message through. (Well, transferring SA comments to a
> multi-line rejection text isn't usually provided.)
>
>

The reason we don't drop is the possibility of false positives. After a
reject, they should be returned to the sender. Also, I like to think that
rejection might persuade a spammer to leave our site alone.

Is there a way of determining which spams are likely to be fed back to the
spammers?


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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 16, 2009, 2:29 AM

Post #46 of 63 (2648 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 14 October 2009 15:08:15 -0700 David MacQuigg
<macquigg [at] ece> wrote:

>
> OK, I think I understand now what you mean by "sender". Sender
> (individual author) addresses are worthless to identify bad senders.
> See above.

That's simply not my experience. I've seen spear phishing attacks from
gmail accounts that are listed on blacklists. The blacklisting of sender
addresses does have value to me.

But, there's a bigger picture here. I'd like to rate-limit new senders that
haven't earned a good reputation. I can do that for individual gmail users,
but can't apply the same rate limit to all gmail users.

Therefore, I need a reputation system that allows me to key on sender
addresses. However, to do that, I need some sort of assurance that the
author address hasn't been spoofed.

Why rate limit? Well, for example, I see about 1% of users responding to
spear-phishing with passwords, and (amusingly, but annoyingly) about 1%
responding with abuse to the phisher, and about 1% reporting the abuse to
me. So, an effective phishing attack requires to hit a few hundred people
at a time. I'd be quite happy with freezing mail in my mail queue in these
circumstances, for new bulk senders from large ESPs, until I can approve it.



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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


stuart at bmsi

Oct 16, 2009, 7:11 AM

Post #47 of 63 (2656 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

On Fri, 16 Oct 2009, Ian Eiloart wrote:

> > The common criterion for dropping is that by rejecting you are providing
> > a free test machine for spammers to keep trying various alternatives
> > until they get the message through. (Well, transferring SA comments to a
> > multi-line rejection text isn't usually provided.)
> >
> >
>
> The reason we don't drop is the possibility of false positives. After a
> reject, they should be returned to the sender. Also, I like to think that
> rejection might persuade a spammer to leave our site alone.
>
> Is there a way of determining which spams are likely to be fed back to the
> spammers?

The REJECT itself is the feedback. The spammer manually or automatically
adjusts the camouflage for the spam until it no longer gets rejected.

--
Stuart D. Gathman <stuart [at] bmsi>
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 [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 16, 2009, 7:41 AM

Post #48 of 63 (2651 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 16 October 2009 10:11:50 -0400 "Stuart D. Gathman" <stuart [at] bmsi>
wrote:

> On Fri, 16 Oct 2009, Ian Eiloart wrote:
>
>> > The common criterion for dropping is that by rejecting you are
>> > providing a free test machine for spammers to keep trying various
>> > alternatives until they get the message through. (Well, transferring
>> > SA comments to a multi-line rejection text isn't usually provided.)
>> >
>> >
>>
>> The reason we don't drop is the possibility of false positives. After a
>> reject, they should be returned to the sender. Also, I like to think that
>> rejection might persuade a spammer to leave our site alone.
>>
>> Is there a way of determining which spams are likely to be fed back to
>> the spammers?
>
> The REJECT itself is the feedback. The spammer manually or automatically
> adjusts the camouflage for the spam until it no longer gets rejected.

Right, but I'll bet that's not universal. For example we saw a big drop in
attempted virus deliveries when we started rejecting them at smtp time. My
theory is that the spambots went and knocked on someone else's door when
they realised they weren't delivering to us.




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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


macquigg at ece

Oct 16, 2009, 8:08 AM

Post #49 of 63 (2646 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

Ian Eiloart wrote:
>
> --On 14 October 2009 15:08:15 -0700 David MacQuigg
> <macquigg [at] ece> wrote:
>
>> OK, I think I understand now what you mean by "sender". Sender
>> (individual author) addresses are worthless to identify bad senders.
>> See above.
>
> That's simply not my experience. I've seen spear phishing attacks from
> gmail accounts that are listed on blacklists. The blacklisting of
> sender addresses does have value to me.

I wasn't aware of any blacklists of individual sender addresses. I
would like to give it a try. Where can I find one?

> But, there's a bigger picture here. I'd like to rate-limit new senders
> that haven't earned a good reputation. I can do that for individual
> gmail users, but can't apply the same rate limit to all gmail users.

I would rather not try to separate good from bad within Gmail. That is
really Gmail's responsibility. I just rate the entire mailflow from
Gmail to our receivers. Whitelisting of individual Gmail authors can be
done by our individual recipients.

> Therefore, I need a reputation system that allows me to key on sender
> addresses. However, to do that, I need some sort of assurance that the
> author address hasn't been spoofed.

Without having some kind of worldwide individual identity system, it
just can't be done. You will always have to rely on the mail submission
agent (MSA) to verify its user accounts. Some are strict, and have no
spammers among their users. Others, like Gmail, are more concerned
about getting new accounts. We need to make the cost of that decision
higher than the cost of losing a few legitimate accounts when new
subscribers find it inconvenient to provide strong individual
identification to their MSAs. We can do that by holding the MSA
responsible.

A global individual ID system will also have major problems with privacy
and anonymity issues. Organizations operating Internet transmitters
have no legitimate reason to hide their identity.

A reliance on individual IDs will also produce a weak reputation
system. There are far too many IDs to keep track of, and the data for
each one is too sparse. Reputation is best accumulated at the highest
level which still has some authority over its domain. az.us is too
high. Nobody in Arizona can control what all the domains do.
(Theoretically they could, but there is no actual delegation of
authority to az.us (no SOA record).) We have chosen pima.az.us as the
optimum level. Pima county can enforce standards for anyone operating a
transmitter under their name.

-- Dave



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com


iane at sussex

Oct 16, 2009, 9:48 AM

Post #50 of 63 (2648 views)
Permalink
Re: SPF, DKIM, and NIH [In reply to]

--On 16 October 2009 08:08:22 -0700 David MacQuigg
<macquigg [at] ece> wrote:

> Ian Eiloart wrote:
>>
>> --On 14 October 2009 15:08:15 -0700 David MacQuigg
>> <macquigg [at] ece> wrote:
>>
>>> OK, I think I understand now what you mean by "sender". Sender
>>> (individual author) addresses are worthless to identify bad senders.
>>> See above.
>>
>> That's simply not my experience. I've seen spear phishing attacks from
>> gmail accounts that are listed on blacklists. The blacklisting of
>> sender addresses does have value to me.
>
> I wasn't aware of any blacklists of individual sender addresses. I would
> like to give it a try. Where can I find one?

<http://www.scamnailer.info/> has a script that will update spamassassin or
clamav configurations with a list of about 14k addresses that have been
used for scamming. I think the S/A rules generalises from those addresses a
little.

>> But, there's a bigger picture here. I'd like to rate-limit new senders
>> that haven't earned a good reputation. I can do that for individual
>> gmail users, but can't apply the same rate limit to all gmail users.
>
> I would rather not try to separate good from bad within Gmail. That is
> really Gmail's responsibility. I just rate the entire mailflow from
> Gmail to our receivers. Whitelisting of individual Gmail authors can be
> done by our individual recipients.

Absolutely, but you want to check the DKIM signature before applying the
whitelist. Otherwise, every whitelist entry is an invitation to spam.

>> Therefore, I need a reputation system that allows me to key on sender
>> addresses. However, to do that, I need some sort of assurance that the
>> author address hasn't been spoofed.
>
> Without having some kind of worldwide individual identity system, it just
> can't be done. You will always have to rely on the mail submission agent
> (MSA) to verify its user accounts. Some are strict, and have no spammers
> among their users. Others, like Gmail, are more concerned about getting
> new accounts. We need to make the cost of that decision higher than the
> cost of losing a few legitimate accounts when new subscribers find it
> inconvenient to provide strong individual identification to their MSAs.
> We can do that by holding the MSA responsible.

No, we can. What I mean by "spoofed" is that the email was sent from the
account that it claims to be sent from. For gmail, for example, a valid
DKIM signature is enough that I can assign reputation to the purported
author. I don't need a worldwide ID system, I just need to know that the
account that I'm judging is the correct one.

As an admin, I can't just reject all gmail email. I have no choice but to
try to distinguish between good and bad senders. However, I can assign a
default reputation to ESPs like gmail, for previously unseen users in their
domain.



>
> A global individual ID system will also have major problems with privacy
> and anonymity issues. Organizations operating Internet transmitters have
> no legitimate reason to hide their identity.
>
> A reliance on individual IDs will also produce a weak reputation system.
> There are far too many IDs to keep track of, and the data for each one is
> too sparse. Reputation is best accumulated at the highest level which
> still has some authority over its domain. az.us is too high. Nobody in
> Arizona can control what all the domains do. (Theoretically they could,
> but there is no actual delegation of authority to az.us (no SOA record).)
> We have chosen pima.az.us as the optimum level. Pima county can enforce
> standards for anyone operating a transmitter under their name.
>
> -- Dave
>
>
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
> Modify Your Subscription: http://www.listbox.com/member/
> [http://www.listbox.com/member/]
>
> Archives: https://www.listbox.com/member/archive/735/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com



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


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

First page Previous page 1 2 3 Next page Last page  View All SPF discuss RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.