ietf-mxcomp
[Top] [All Lists]

Re: Wide-Open MADRID

2004-05-31 15:32:04


Cheers Damon, nice to see you give your time to 
discuss these ideas! You are still using the 
same MTA software?

 Limiting SPF to class C addresses does not break 
 anything... it is a enhancement. It allows me to 
 do MY job efficiently and effectively. 

See below. 

I sure hope that most in this group will step back, 
take a look at what they are suggesting, imagine the 
poor shmoe that has to implement and administer it 
(please assume that he or she has a life), then modify 
it accordingly. (which is all I am trying to accomplish 
here)

SPF will probably take a few rounds after real life 
has taken a test bite - I am certain that all facets that 
don't pan out will be fixed or removed.
 
If SPF was implemented tomorrow and everyone put a 
record of +all - SPF means nothing, does nothing, can 
do... nothing. It can't even legitimize the IP that 
it is coming from... which is its whole purpose.
Legitimate mailers who do not want to be spoofed, 
will limit their SPF's to class C anyway. Why not 
make it a requirement?

I am truly interested in the work this group is doing. 
I also want to ensure the "product" viable, implementable, 
valuable, and sane.

<rant>
 Adding "Reputation Filters" into this discussion was a 
 play at forwarding your own champion.

 I personally do not like the idea of reputation filters 
 in their current form. Don't get me wrong, they have 
 their place- but not as a RFC'd requirement.
</rant>

 But again, I was not asking about them in my original 
 post. I was asking (and I will ask again)- Can we limit 
 SPF's to Class C addresses?

 If the answer is "No." Then thank you very much- I will 
 consider anyone with over /24 or +all as a spammer and 
 block them. Darn, THAT was easy!

I believe the authors of SPF want to keep it as open as possible, 
so as not to limit the way you use mail but give you powerful tools 
to manage it. As such there are always complexities. The authors 
also state in their drafts that every implementor/administrator is free 
to perform any action he wants given the response to SPF queries. 
So if you want to deny any SMTP transaction which results in +all, 
just as with every SMTP transaction today that gives results based 
on content filtering or dns bl's etc. 

In all of this there is a switch from validating sender ip addresses 
(as being the primary validation) to the sender domain. This is an 
important switch and it is much easier to block based on domains 
and perhaps based on domain dns bl's. Reputiation may play an 
important role in all of this whether you like it or not, blacklists or 
whitelists are nothing but such services, senderbase and spamcop 
as well... 


Rgds,
-GSH


<Prev in Thread] Current Thread [Next in Thread>