headers
Stuart D. Gathman | 1 Jul 2005 01:04

Re: Community Vote: Official Project Domains -- Results

On Wed, 29 Jun 2005, william(at)elan.net wrote:

> That is up to Wayne what he wants to do with those domains, but I 
> certainly expect to have spf-mail still be available for projects
> further use if the need arises later in the next 2 years. Good names
> that have considerable interest from the community should not be
> discarded right away as situation and project needs may change.

Right.  Consider when we get around to working on spf3.0 after
a huge successful deployment of v=spf1.  The installed base will want to
keep up to date on tweaks to SPF classic at the spfclassic.org site,
while openspf.org will be focused on the new developing standard.

--

-- 
	      Stuart D. Gathman <stuart <at> bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
Permalink | Reply | 3 comments |
headers
Hector Santos | 1 Jul 2005 01:36
Favicon

Re: Border Appliances


From: "Stuart D. Gathman" <stuart <at> bmsi.com>

>> With your method, while excellent, you still able to
>> pass undetected spam to users.  Right?

> Correct.  With a relaxed SPF result, and not one of the domains
> already required to be strict.  You see, there are still users
> on small domains that send mail from laptops at hotels without
> SMTP AUTH.

You don't require your roaming uses to be authorized by SMTP AUTH? how about
POP before SMTP?   I guess, you would only allow local mail submissions
only, right? <g>

> But here is the next thing I do.  When accepting
> a relaxed result, I send a dsn.  If the DSN is not accepted,
> I reject the mail.  This weeds out obvious forgeries where the sender
> email doesn't even exist.  If the DSN is accepted, I log who I
> have sent DSNs to, and send them another one every month to
> nag them a bit to secure their system.  Here is the template
> for the softfail DSN:

What's your experience on the feedback on this?

Do you see some changing?

Do you send it every month regardless if they have not sent mail within 1-2
months??  Or do you wait until the next message for the next month?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hector Santos | 1 Jul 2005 02:18
Favicon

Re: Border Appliances


----- Original Message -----
From: "Stuart D. Gathman" <stuart <at> bmsi.com>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss <at> v2.listbox.com>
Sent: Thursday, June 30, 2005 6:49 PM
Subject: Re: [spf-discuss] Border Appliances

> On Thu, 30 Jun 2005, Hector Santos wrote:
>
>>> reject_neutral = aol.com, yahoo.com, hotmail.com, arosii.com,
>>>         oracle.com, msn.com, rr.com, egroups.com, gmail.com

> Bet you can't guess which of the above domains has the most forged
> spam sent to my system.

How much you got?  <g>

Hmmm, maybe this is trick question.

Well, taking a SWAG based on our own stats,  I can tell you of the domains I
know.  Not familar with arosii.com....

You have a POST SMTP "CBV" like concept using DSN,  we use a pure CBV at the
SMTP level.

This means you have a much higher payload scalability issue.  For a large
system with a high spam ratio, that would be a tremendous amount of
overhead.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stuart D. Gathman | 1 Jul 2005 05:34

Re: Border Appliances

On Thu, 30 Jun 2005, Hector Santos wrote:

> You don't require your roaming uses to be authorized by SMTP AUTH? how about
> POP before SMTP?   I guess, you would only allow local mail submissions
> only, right? <g>

I'm not talking about *my* users.  I'm talking about some other
mail admin's users that want to send my users mail.

> > But here is the next thing I do.  When accepting
> > a relaxed result, I send a dsn.  If the DSN is not accepted,
> 
> What's your experience on the feedback on this?

The DSNs are mostly ignored.  But I have gotten several replies 
from mail admins thanking me for the info.  The problem is that
users rarely inform the mail admin of the DSN.  And I don't feel
right about spamming postmaster with every DSN intended for
one of their users.

> Do you see some changing?

Yes.  One admin told me he had been wanting to setup SMTP AUTH to
improve security, but hadn't had a kick in the butt.  The DSNs were just what
he needed.  He hadn't heard about SPF, and published after setting his
roaming users up with SMTP AUTH.

> Do you send it every month regardless if they have not sent mail within 1-2
> months??  Or do you wait until the next message for the next month?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stuart D. Gathman | 1 Jul 2005 05:49

Re: Border Appliances

On Thu, 30 Jun 2005, Hector Santos wrote:

> You have a POST SMTP "CBV" like concept using DSN,  we use a pure CBV at the
> SMTP level.

I could do that too, but then I couldn't quote the Subject or other
parts of the message.

> This means you have a much higher payload scalability issue.  For a large
> system with a high spam ratio, that would be a tremendous amount of
> overhead.

Very few messages get as far as the DSN.  And we get >30000 spams per day
vs <100 real emails.  There are many other layers.  The simplest layer
that cans the most forgery is the HELO blacklist.  I blow off 
connections from MTAs that use my own domain in the HELO.  The second
most effective is to blow off HELOs with a numeric IP (not allowed 
by rfc2821, and I've never seen a real email that does it).  That's 
just for starters.

> In other words, I bet you will get the same near result with a much greater
> efficiency by doing a CBV at SMTP instead, rather than receive your payload
> first.

The main purpose of the DSN is to annoy people that have misconfigured
mail systems.  In addition to softfail, the DSN is sent for systems
with missing/invalid PTR, invalid HELO, and no SPF record or neutral
result.  They need to get one of the 3 right so I have a domain to
block if needed.  The CBV aspect is a side benefit.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Connor | 1 Jul 2005 09:09

Another attempt at showing some stats

I have done a bit more work on my stats-gathering script, and I'm a little 
more confident in the numbers.  I'm attaching a CSV file... these are my 
results upon running the script for 4 hours or so.

I haven't really drawn any conclusions from the numbers, and in itself it's 
probably not enough to conclude or decide anything, other than "we need 
more data about X and Y areas".  But, I wanted to get the information out 
there, to see if other folks have opinions, questions, comparisons, etc.

The plain-text, single-column version appears below, in case the CSV 
doesn't make it through.

Some SPF results are broken down further by:
  /local-policy : best guess was applied
  /sgi.com      : override for our company which doesn't actually publish 
spf yet

Complete tally of SPF results, not broken down by action/disposition.  This 
is all with best guess on, and trusted-forwarder whitelist.

85.77%	(null sender)
0.06%	error
0.45%	error/local policy
0.00%	error/sgi.com
0.06%	error/*.sgi.com
0.59%	fail
1.26%	fail/*.sgi.com
0.09%	fail/sgi.com
2.06%	neutral
7.79%	neutral/local policy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hector Santos | 1 Jul 2005 10:30
Favicon

Re: Border Appliances


From: "Stuart D. Gathman" <stuart <at> bmsi.com>

> I'm not talking about *my* users.  I'm talking about some other
> mail admin's users that want to send my users mail.

No I understood.  Right, Anonymous Final Destination (AFD) mail behavior
where you don't have to authorize the sender to submit mail to your local
users - the #1 loophole in SMTP. <g>

> > What's your experience on the feedback on this?
>
> The DSNs are mostly ignored.  But I have gotten several replies
> from mail admins thanking me for the info.  The problem is that
> users rarely inform the mail admin of the DSN.  And I don't feel
> right about spamming postmaster with every DSN intended for
> one of their users.

Ok, thanks for this feedback.  Right,  reporting stuff of this nature would
need to be done in a professional manner to the sysop, but as a group/domain
policy issue. For example, you might consider just sending the first time
the domain is tried on your system.  You are going to get the relaxed result
for all users, so it should be done as a group/domain policy.

But you done some form of reporting, I have not.  Good feedback. You got my
interest in pushing this work agenda up.

> > Do you see some changing?
>
> Yes.  One admin told me he had been wanting to setup SMTP AUTH to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Hammer | 1 Jul 2005 15:08
Picon

Re: Community Vote: Official Project Domains -- Results

On 6/30/05, Stuart D. Gathman <stuart <at> bmsi.com> wrote:

> 
> Right.  Consider when we get around to working on spf3.0 after
> a huge successful deployment of v=spf1.  The installed base will want to
> keep up to date on tweaks to SPF classic at the spfclassic.org site,
> while openspf.org will be focused on the new developing standard.

Stuart, This makes no sense. People want a single place (portal) to go
to for official information. This is about branding and mindshare. The
more appropriate way to handle the situation you lay out is:

classic.openspf.org or openspf.org/classic/ (leaving out the www.)

As usual, just my 2 cents.

Mike
Permalink | Reply | 2 comments |
headers
Julian Mehnle | 1 Jul 2005 15:31
Gravatar

Re: Community Vote: Official Project Domains -- Results


Michael Hammer wrote:
> On 6/30/05, Stuart D. Gathman <stuart <at> bmsi.com> wrote:
> > Right.  Consider when we get around to working on spf3.0 after
> > a huge successful deployment of v=spf1.  The installed base will want
> > to keep up to date on tweaks to SPF classic at the spfclassic.org
> > site, while openspf.org will be focused on the new developing
> > standard.
>
> Stuart, This makes no sense. People want a single place (portal) to go
> to for official information. This is about branding and mindshare. The
> more appropriate way to handle the situation you lay out is:
>
> classic.openspf.org or openspf.org/classic/ (leaving out the www.)

I agree with Michael.  We shouldn't have separate sites for different 
versions of SPF.
Permalink | Reply | 0 comments |
headers
Stuart D. Gathman | 1 Jul 2005 15:49

Re: Community Vote: Official Project Domains -- Results

On Fri, 1 Jul 2005, Michael Hammer wrote:

> Stuart, This makes no sense. People want a single place (portal) to go
> to for official information. This is about branding and mindshare. The
> more appropriate way to handle the situation you lay out is:
> 
> classic.openspf.org or openspf.org/classic/ (leaving out the www.)

That is good too.  I wasn't totally serious. 

--

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

Gmane