You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Charles Gregory <cg...@hwcn.org> on 2009/04/30 20:24:24 UTC

Personal SPF

Hello!

Wild idea time: I won't be surprised if this is shot down...

Proposal: "Personal SPF" - A DNS-based lookup system to allow individual 
sender's of e-mail to publish a *personal* SPF record within the context 
of their domain's SPF records, that would identify an IP or range of IP's 
which they would be 'stating' are the only possible sources of their mail.

Why 'personal'? Because I run an ISP where user's *may* send their mail 
via any number of DSL connections, so I can't publish 'positive' SPF 
records for our whole domain. But if I could have member's opt-in to a 
'personal' registry, and have spamassassin check for 
'1.1.1.1.address.personalspf.domain.tld' and treat it like an SPF lookup, 
then a lot of people who currently do not enjoy SPF protection could 'sign 
up' and help clear the iway of junk. :)

A sender could 'opt-in' with a range of addresses, or, if the sender does 
not choose one, they get a 'neutral' result. Totally non-existent 
addresses would get a special response to distinguish the result from 
simple 'host not found' responses, and thus this Personal SPF could also 
serve as a more efficient mechanism for sender existence verification.

Such a mechanism would enjoy the benefits of DNS caching, and avoid the 
problematic aspects of sender 'callback' SMTP verification, which, the 
more I read, the less I like. :(

Obviously there would be 'details' to work out, but fundamentally, the 
question is, would the same mechanism that handles SPF be able to handle 
the additional 'load' of personal SPF? Or would this be a bigger burden 
than SMTP callbacks?

- Charles

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
Welcome to English 101.....

>>>>  Configuring the mail account in their MUA independently on their
>>>>  internet connection is much easier than changing SMTP server every
>>>>  time they connect to other network.

Poster is saying it is easier to setup port 587 in MUA instead of 
configuring PSPF....

>>> This really is an important point. Your current system makes things
>>> unnecessarily difficult for roadwarriors.

Another poster offers a good supporting reason to use 587 in MUA 
(regardless of PSPF).

> On 05.05.09 10:48, Charles Gregory wrote:
>> Roadwarriors (cute term, BTW) form a very small proportion of my users,
>> but even so, the solution for them is 5 minutes setup. I *will* be
>> implementing it.

I say the last argument only covers a small portion of my users, BUT it is 
so easy to setup (only 5 minutes for me on my server), I *will* be 
implementing the first poster's suggestion (port 587 with smtp auth).

Matus UHLAR - fantomas wrote:
> 5 minutes of setup every time they change internet connection...
> and even non-road-warriors will have to change that every time they change
> connection.

People see what they want to see......

I welcome reasoned debate, but that has to start with reading what people 
are actually saying, and not interpreting every sentence with the worst 
possible attitude.

- Charles

Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> On 04.05.09 10:31, Charles Gregory wrote:
>>> >  OUR mail server *requires* that a user be connected via our dialups.
>>>  Configuring the mail account in their MUA independently on their internet
>>>  connection is much easier than changing SMTP server every time they
>>>  connect to other network.

> On Tue, 5 May 2009, Jonas Eckerman wrote:
>> This really is an important point. Your current system makes things  
>> unnecessarily difficult for roadwarriors.

On 05.05.09 10:48, Charles Gregory wrote:
> Roadwarriors (cute term, BTW) form a very small proportion of my users,  
> but even so, the solution for them is 5 minutes setup. I *will* be  
> implementing it.

5 minutes of setup every time they change internet connection... 
and even non-road-warriors will have to change that every time they change
connection.

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory. 

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 5 May 2009, Jonas Eckerman wrote:
> On 04.05.09 10:31, Charles Gregory wrote:
>> >  OUR mail server *requires* that a user be connected via our dialups.
>>  Configuring the mail account in their MUA independently on their internet
>>  connection is much easier than changing SMTP server every time they
>>  connect to other network.
> This really is an important point. Your current system makes things 
> unnecessarily difficult for roadwarriors.

Roadwarriors (cute term, BTW) form a very small proportion of my users, 
but even so, the solution for them is 5 minutes setup. I *will* be 
implementing it.

Of course, this changes the balance of 'need'. I would still like to 
discuss the idea of Personal SPF, and answer the questions I originally 
asked about possible loads and impact. But it may prove to be there are 
too few people who would benefit from it to make it worth the effort.
(shrug) Doesn't matter really, as long as we *think* about it.

-C

Re: Personal SPF

Posted by Jonas Eckerman <jo...@frukt.org>.
On 04.05.09 10:31, Charles Gregory wrote:
 >> OUR mail server *requires* that a user be connected via our dialups.

[...]

Matus UHLAR - fantomas wrote:

> Configuring the mail account in their MUA independently on their internet
> connection is much easier than changing SMTP server every time they connect
> to other network.


This really is an important point. Your current system makes things 
unnecessarily difficult for roadwarriors.

Beeing able to use authenticated SMTP to port 587 at *one* address is 
much easier than having to set up different outgoing servers for 
different connections wich can become quite tedious if you tend to use 
the connections provioded by hotels for example.

FWIW, this was actually the main justification here for setting up 
authenticated SMTP using a custom SMTP proxy wich authenticated against 
different (local) POP mailboxes depending on user name and server IP. 
Our users (me included) understandably wanted mail on laptops to be easier.

The possibility of using SPF and DKIM were just bonuses.

/Jonas

-- 
Jonas Eckerman
Fruktträdet & Förbundet Sveriges Dövblinda
http://www.fsdb.org/
http://www.frukt.org/
http://whatever.frukt.org/

Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Tue, 5 May 2009, Mike Cardwell wrote:
>> For what it's worth I also think this personal SPF concept is a 
>> terrible idea with zero chance of taking off. And I actually *like* 
>> normal SPF.

On 05.05.09 10:39, Charles Gregory wrote:
> Well, it would be nice if you offered some reasons *why* you feel this  
> way. I said up front that I had a strong suspicion this wouldn't fly, but 
> I was expecting a bit more reasoning than people just contradicting me...

I think he just did not want to repeat what was already said here, just to
note he argrees with it. 
-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I feel like I'm diagonally parked in a parallel universe. 

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
Footnote: Just had one of my users report the same problem on another 
list. So my suspicion that this is on *my* server seems well-founded...

On Tue, 5 May 2009, Charles Gregory wrote:
> OT : Apologies if I miss any replies to my posts. But they are getting lost 
> in a pile of repeats....
>
> For some reason I am getting many multiple copies of all the
> posts from this mailing list. If the list admin is listening in,
> would he/she be kind enough to check SMTP logs for connections to
> 'barton.hwcn.org' (my mail server) and see if any errors are reported
> on the sending side of the connection? I suspect that some sort of
> time-out is occurring before my server acknowledges receipt, and so while my 
> SMTP finishes delivering the message, your server is considering it a failed 
> send, and trying again multiple times....
>
> - Charles
>
>

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
OT : Apologies if I miss any replies to my posts. But they are getting 
lost in a pile of repeats....

For some reason I am getting many multiple copies of all the
posts from this mailing list. If the list admin is listening in,
would he/she be kind enough to check SMTP logs for connections to
'barton.hwcn.org' (my mail server) and see if any errors are reported
on the sending side of the connection? I suspect that some sort of
time-out is occurring before my server acknowledges receipt, and so while 
my SMTP finishes delivering the message, your server is considering it a 
failed send, and trying again multiple times....

- Charles

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 5 May 2009, LuKreme wrote:
>> > For what it's worth I also think this personal SPF concept is a terrible 
>> > idea with zero chance of taking off. And I actually *like* normal SPF.
>> Well, it would be nice if you offered some reasons *why* you feel this way.
> I did in the portion of the message you snipped.
> "If you have mail accounts for users who are not on your network then you 
> have an obligation to allow those users access to your mailserver."

No, that is not a reason why MY idea is 'terrible'. It is an argument in 
favor of an alternate idea. At best, you are arguing that my idea would be 
'unnecessary', without truly addressing the technical issues I am seeking 
answers to. You might as well suggest that if we all started writing our 
mail on scraps of paper that we wouldn't need my idea either. But as long 
as the real world has people sending mail via multiple servers, it would 
be nice if we could figure out a clever way to authenticate their 
validity.

- Charles

Re: Personal SPF

Posted by Mike Cardwell <sp...@lists.grepular.com>.
LuKreme wrote:

>>> For what it's worth I also think this personal SPF concept is a 
>>> terrible idea with zero chance of taking off. And I actually *like* 
>>> normal SPF.
>>
>> Well, it would be nice if you offered some reasons *why* you feel this 
>> way.
> 
> I did in the portion of the message you snipped.
> 
> "If you have mail accounts for users who are not on your network then 
> you have an obligation to allow those users access to your mailserver."

He was responding to me in that email, not you. I just didn't want to 
repeat what everyone else had already said.

-- 
Mike Cardwell
(https://secure.grepular.com/) (http://perlcv.com/)

Re: Personal SPF

Posted by LuKreme <kr...@kreme.com>.
On 5-May-2009, at 08:39, Charles Gregory wrote:
> On Tue, 5 May 2009, Mike Cardwell wrote:
>> For what it's worth I also think this personal SPF concept is a  
>> terrible idea with zero chance of taking off. And I actually *like*  
>> normal SPF.
>
> Well, it would be nice if you offered some reasons *why* you feel  
> this way.

I did in the portion of the message you snipped.

"If you have mail accounts for users who are not on your network then  
you have an obligation to allow those users access to your mailserver."


-- 
Kickboxing. Sport of the future.


Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 5 May 2009, Mike Cardwell wrote:
> For what it's worth I also think this personal SPF concept is a terrible 
> idea with zero chance of taking off. And I actually *like* normal SPF.

Well, it would be nice if you offered some reasons *why* you feel this 
way. I said up front that I had a strong suspicion this wouldn't fly, but 
I was expecting a bit more reasoning than people just contradicting me...

- C

Re: Personal SPF

Posted by Benny Pedersen <me...@junc.org>.
On Tue, May 5, 2009 10:33, Mike Cardwell wrote:
>> Please, stop the PSPF discussions and go implement something that will
>> work without changing the whole internet
> For what it's worth I also think this personal SPF concept is a terrible
> idea with zero chance of taking off. And I actually *like* normal SPF.

it will work if the recipient whitelist based on PSPF without thinking how
SPF works :)

-- 
http://localhost/ 100% uptime and 100% mirrored :)


Re: Personal SPF

Posted by Mike Cardwell <sp...@lists.grepular.com>.
Matus UHLAR - fantomas wrote:

> Please, stop the PSPF discussions and go implement something that will
> work without changing the whole internet

For what it's worth I also think this personal SPF concept is a terrible 
idea with zero chance of taking off. And I actually *like* normal SPF.

-- 
Mike Cardwell
(https://secure.grepular.com/) (http://perlcv.com/)

Re: Personal SPF

Posted by "J.D. Falk" <jd...@cybernothing.org>.
John Hardin wrote:
> On Tue, 5 May 2009, Jonas Eckerman wrote:
>
>> I can't speak for others, but this is one reason why I haven't given
>> my opinions about your proposed PSPF.
>
> +1.
>
> If this OT discussion is going to get discourteous, please take it
> somewhere more appropriate.

+1

If it were to become courteous again, one of the IETF lists might be 
appropriate -- that's where the standard would be developed, after all.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Re: Personal SPF

Posted by John Hardin <jh...@impsec.org>.
On Tue, 5 May 2009, Jonas Eckerman wrote:

> I can't speak for others, but this is one reason why I haven't given my 
> opinions about your proposed PSPF.

+1.

If this OT discussion is going to get discourteous, please take it 
somewhere more appropriate.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Think Microsoft cares about your needs at all?
   "A company wanted to hold off on upgrading Microsoft Office for a
   year in order to do other projects. So Microsoft gave a 'free' copy
   of the new Office to the CEO -- a copy that of course generated
   errors for anyone else in the firm reading his documents. The CEO
   got tired of getting the 'please re-send in XX format' so he
   ordered other projects put on hold and the Office upgrade to be top
   priority."                                    -- Cringely, 4/8/2004
-----------------------------------------------------------------------
  3 days until the 64th anniversary of VE day

Re: Personal SPF

Posted by Jonas Eckerman <jo...@frukt.org>.
Charles Gregory wrote:

>> Please, stop the PSPF discussions and go implement something that will
>> work without changing the whole internet

> LOL! Please stop discussing ideas?

To be fair, this is the SpamAssassin users list. The purpose if this 
list isn't the discussion about the validity of ideas about possible 
future extensions to SPF, DKIM or whatever except as to how those ideas 
might have a direct impact on the usage or development of SpamAssassin.

I can't speak for others, but this is one reason why I haven't given my 
opinions about your proposed PSPF.

Regards
/Jonas
-- 
Jonas Eckerman
Fruktträdet & Förbundet Sveriges Dövblinda
http://www.fsdb.org/
http://www.frukt.org/
http://whatever.frukt.org/


Re: Personal SPF

Posted by Bill Landry <bi...@inetmsg.com>.
Ok, this horse is not only dead, but it's been totally pulverized.  Can
we now please kill this ridiculously drawn-out thread - or maybe it can
be taken off-line by those that wish to continue this diatribe?

Thanks!

Bill

Re: Personal SPF

Posted by LuKreme <kr...@kreme.com>.
On 6-May-2009, at 08:50, Charles Gregory wrote:
> On Tue, 5 May 2009, Mark wrote:
>> Only several posts ago you had never even heard of SMTP AUTH....
>
> I mentioned it in my original post. But let's just ignore this small  
> factual error and continue....

No you didn't.  The string 'auth' does not appear in your original  
email  <al...@barton.hwcn.org> nor does  
your original message contain anything that is remotely similar to  
SMTP AUTH.

>> ... or how folks generally solve their roaming user problem by  
>> means of having them connect to 'submission' port 587.
>
> Granted. And upon being informed of this new development,

Submission is not new, it is only new *to you*. It may be new in the  
way that UUCP is 'old', that's about it.

> I indicated my approval of the idea, and that I would be  
> implementing it. But it didn't address the rest of the 'needs' I  
> expressed....

The only needs you expressed was some way of creating an email address  
specific SPF list using DNS and of avoiding 'callback'.

> Saying "that is bad" or "that is good" gives me NOTHING on which to  
> make my *own* less-ignorant judgement in future.


You posted an idea without, obviously, doing actual research. You were  
quite vocal and bellicose in your defense of this idea in the face of  
several quite knowledgeable people telling you it was a bad idea.  
Granted, the first replies were more in the vein of 'do this instead'  
and 'this is the right way to do it', but you continued to insist you  
wanted some entirely new thing. It was at this point that people said,  
"no, this is stupid", before that Matus and Jonas and others were  
simply trying to point you in the right direction.

> The person who told me about 587 wasn't particularly nice. But he  
> was VERY informative. So I thank him for it. :)

Really?  i beg to differ:

On 4-May-2009, at 10:17, Matus UHLAR - fantomas wrote:
> The mail can be sent using other ports, 587 is well defined for mail
> submission and 465 can be user for the same reason (with SSL) as my  
> company
> does. However submitting mail via other ports should require  
> authentication,
> and if anyone does not, it's completely their problem.

Unless by 'not nice' you mean 'failed to blow the requisite smoke up  
my ass' that was a perfectly polite and non-hostile reply.

> "The netload of DNS lookups for individual addresses would overtax  
> the DNS caching (or bandwidth)?"

But that isn't even WHY it's a bad idea.  It's a bad idea for many  
reason, including that one, but that one is nowhere near the top of  
the list.

> That's the answer I was really expecting. But I am *ignorant* of  
> those facts, and that's why I asked.

You asked a question, were presented with *the right way* to solve  
your problem.  You did not want the *right way* you wanted to talk  
about your suggestion to fix your problem and ignore everyone else  
telling you how to actually fix it.

>> Way I see it, your idea was shot down....
>
> No, my idea was DISMISSED.

because it was a *STUPID* idea based on your ignorance. Sorry to be so  
blunt, but there it is. You were given the right solution several  
times in the first 5 or 6 replies.

> Small difference. An idea is 'shot down' when someone presents  
> rational arguments and reasons for WHY it is bad.

You know, that's pretty self-involved and self-aggrandizing. You are  
assuming that your idea merited that sort of time, thought, and  
effort. It didn't. It was a ridiculous idea on its face and anyone who  
works with mailservers would know that. It's much as if you posted  
that you though all engine blocks should be made of chocolate. Do you  
think anyone is going to take the time to explain WHY chocolate is a  
bad idea for an engine block, or are they going to DISMISS your idea  
and say, "No, the right materials for engine blocks are well  
established. Engine blocks are made like THIS."

> Sure, I missed the 587 thing, but once I googled for it, I could see  
> that it is still relatively new,

Yeah... let's see, I setup submission on my mailserver in... um...  
1997?  1999?  I know it dates back to at least RFC2476 (1998) but I  
think it's older than that, perhaps unofficially, but it is still  
documented more than a decade old.

> not even yet programmed as any standard into MUA's

Yeah, that's completely false.

> I'm not embarrased to have missed it.

Yes, well you *should* be.

> It wasn't a gross error. Again, this is WHY I ask the questions on  
> this group.

but you IGNORED those answers and insisted that you had a good idea.

>> .... there's always the bloke-du-jour who comes up with a  
>> 'brilliant' new, often elaborate, plan to do things differently.  
>> And usually, like in your case, they haven't done their homework  
>> first.
>
> More arrogance. I *did* do some homework.

There is absolutely zero evidence of that in your initial post.

>> decided to forego on finding out how people have been solving these  
>> issues for the last ten years.
>
> If the issues were "solved" then why do they still exist?

Because there are people like you in charge of mailservers? I mean,  
that's PART of the reason at least. "Damn those remote users, we can't  
let them have access to our precious mailserver" is a very bad  
attitude and one of the things that keeps SPF from being more useful.

> Why isn't everyone useing SPF and happy? It's not just ignorance and  
> inertia. It's situations like the one I described.

Caused by laziness and the inability to move your mailserver into the  
21st century.  Are you still running SpamAssassin 2.0 also?

> A lazy choice is still a choice, and if people are going to make  
> them, then it stands to reason that we need to find ways to work  
> *with* the way people think/act

And yet your proposal was to force YOUR USERS to reconfigure their MUA  
*AND* a DNS record every time their IP changes. My in-laws DSL IP  
changes every six hours. That is not working with people, that is  
working actively *against* them.

> rather than continue to just arrogantly insist they do it 'our' way.

Yes, damn those helpful people for giving you a SOLUTION instead of  
arguing about the merits of your stupid idea.

> Firstly, you keep *saying* it would be 'complicated' and 'hard to  
> implement',

I'll go further. It would be complicated and IMPOSSIBLE to implement  
and would create massive security holes and would be a completely  
worthless anti-spam indicator. It defies the very first rule on 21st  
century email, which is that the server responsible for sending mail  
has to *know* who the sender is.

> which I suppose is a little bit better than just saying 'bad', but  
> not much. You don't say HOW it would be so.

That because the vast majority of people on this list, at least  
replying to you, know by looking at it that it's senseless and that  
you are going about solving your problem the exactly ass-backwards  
way.  So they provide you with the RIGHT way, and you get petulant  
because they aren't responding to your 'clever' idea.

> It has the sound of someone *assuming* that it would be so. I  
> haven't bothered to contradict this notion, but truthfully, I  
> wouldn't advance the idea if I didn't have a feeling that it *might*  
> be easy to implement.

Which only goes to show that 1) you've learned nothing 2) you don't  
have a clue what you are talking about and 3) you've ignored the  
people who quite obviously know a lot more than you do [and just to be  
clear, I am talking about Matus and Mike and others, not even myself].  
As far as I am concerned, the mere fact that it is user-hostile means  
that it is a complete non-starter and not worth considering. Much as I  
would not consider an idea that required, say, submitting a blood- 
sample for every email you send, or a pay-to-send scheme, or a prove- 
you-love-me scheme.  these are all stupid ideas, but only one of them  
is MORE stupid than yours. I don't even need to look for another  
reason, but trust me, those other reasons are Legion.

> Well, this thread is going to end anyway, because according to  
> Occam's logic, I can sure as asterisks tell that no one around here  
> is really going to give me a serious reply.

Post a serious suggestion and you will get a serious reply. I posted a  
serious suggestion about the same time as your laughable one and, even  
though it looks like it's not likely to work--or at least not well  
enough to make it worth implementing, it got serious discussion for 25  
messages or so.


-- 


Re: [sa] RE: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Wed, 6 May 2009, Mike Cardwell wrote:
> "I have an idea which involves deleting every third character of your email 
> to make it route over the Internet faster. What do you think?"
> People wouldn't respond with, "That's a bad idea because x", they'd respond 
> with "Don't be stupid", and "That's a crap idea." And I'd thank them for it, 
> and commit myself.

You honestly got a laugh out of me there. You know, whether I agree or 
not with what people think of my idea, this analogy sure clarifies why I'm 
getting all the attitude. Thanks.... I think. (grin)

- C

Re: [sa] RE: Personal SPF

Posted by Mike Cardwell <sp...@lists.grepular.com>.
Charles Gregory wrote:

>> Okay, enough with the righteous indignation already.
> 
> You know, if people put as much effort into my idea as they have into 
> 'putting me in my place', there could be some really great discussions.
> Sigh...

> Granted. And upon being informed of this new development, I indicated my 
> approval of the idea, and that I would be implementing it. But it didn't 
> address the rest of the 'needs' I expressed....

It's not a "new" development. http://www.ietf.org/rfc/rfc2476.txt is 
over 10 years old.

Anyway. I'm sick of this thread. Here's a short list of reasons why 
personal spf will never work:

1.) 99.9% + of users aren't technical enough to understand it or 
understand why they would need it.
2.) 99.99% + of users wouldn't benefit from it at all as 99.99% + of 
users don't get spoofed.
3.) 99.999% + of mail providers wouldn't have the resources or be 
willing to put in the effort required to build a custom application for 
their systems to accept pspf submissions from their users.

If it was just a bad idea, you'd probably have got a better explanation 
as to why, but it's not just a bad idea is it ... it's such a terrible 
terrible idea you shouldn't expect people to take the time out of their 
day to even tell you why. If I sent an email to the list saying:

"I have an idea which involves deleting every third character of your 
email to make it route over the Internet faster. What do you think?"

People wouldn't respond with, "That's a bad idea because x", they'd 
respond with "Don't be stupid", and "That's a crap idea." And I'd thank 
them for it, and commit myself.

-- 
Mike Cardwell
(https://secure.grepular.com/) (http://perlcv.com/)

Re: [sa] RE: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 5 May 2009, Mark wrote:
> Okay, enough with the righteous indignation already.

You know, if people put as much effort into my idea as they have into 
'putting me in my place', there could be some really great discussions.
Sigh...

> Only several posts ago you had never even heard of SMTP AUTH....

I mentioned it in my original post. But let's just ignore this small 
factual error and continue....

> ... or how folks generally solve their roaming user problem by means of 
> having them connect to 'submission' port 587.

Granted. And upon being informed of this new development, I indicated my 
approval of the idea, and that I would be implementing it. But it didn't 
address the rest of the 'needs' I expressed....

> So, perhaps peeps could have been nicer about your ignorance;

I don't care if people are 'nice'. I care that they actually say things 
that END the ignorance. Saying "that is bad" or "that is good" gives
me NOTHING on which to make my *own* less-ignorant judgement in future.
The person who told me about 587 wasn't particularly nice. But he was VERY 
informative. So I thank him for it. :)

> but the ignorance itself was squarely yours. Live with it.

Well, if no one is going to bother to enlighten me, then yeah, I guess 
we'll all have to live with it. But wouldn't it be simpler to say,
"The netload of DNS lookups for individual addresses would overtax the DNS 
caching (or bandwidth)?" That's the answer I was really expecting. But
I am *ignorant* of those facts, and that's why I asked.

> Way I see it, your idea was shot down....

No, my idea was DISMISSED. Small difference. An idea is 'shot down' when 
someone presents rational arguments and reasons for WHY it is bad. Not 
just *saying* it is 'bad'. Perhaps 'slapped down' would be the best phrase 
for what has happened here.

> ... not because of any alleged arrogance on 'our' end, but simply 
> because folks like you are a dime a dozen, these days;

ROFL No arrogance there, oh no.....

Oh, and just to be clear, "arrogance" does NOT mean that you should not 
feel or say that you know more than me. You do. At least in some areas. I 
mean, that's why I asked questions of this group. No, "arrogance" is what 
happens when those who know "more" feel that those like me who know "less" 
are not *deserving* of an explanation. I mean, really, if my idea came up 
before, then somewhere there is already a discussion on it, and it would 
hardly take much effort to say, "RTFM - LINK". Oh, and it is also 
"arrogant" to presume that someone hasn't done ANY reading on a subject.
Sure, I missed the 587 thing, but once I googled for it, I could see that 
it is still relatively new, not even yet programmed as any standard into 
MUA's, and so on. I'm not embarrased to have missed it. It wasn't a gross 
error. Again, this is WHY I ask the questions on this group.

> .... there's always the bloke-du-jour who comes up with a 'brilliant' 
> new, often elaborate, plan to do things differently. And usually, like 
> in your case, they haven't done their homework first.

More arrogance. I *did* do some homework. And even if I didn't know about 
the port 587 thing, I did make it clear that I had an overall reason to 
avoid the whole SMTP option, and I was looking for alternatives. Arrogance 
is to presume that because you have decided on the 'best' way that I must 
somehow be stupid or 'not do my homework' because I want a differen way.

> .... Instead, thinking your idea was God's gift to earth ....

More irony. You throw accusations at me that better suit your pedantic 
refusal to even *consider* or *discuss* a 'bad' idea. "God's gift to 
Earth" is the person who believes his idea is so unquestionable that he 
won't dicuss it, but just tell people that they are "ignorant" because 
they don't accept *your* pronouncement.

> decided to forego on finding out how people have been solving these 
> issues for the last ten years.

If the issues were "solved" then why do they still exist? Why isn't 
everyone useing SPF and happy? It's not just ignorance and inertia. It's 
situations like the one I described. A lazy choice is still a choice, and 
if people are going to make them, then it stands to reason that we need to 
find ways to work *with* the way people think/act rather than continue to 
just arrogantly insist they do it 'our' way. Well, I mean, if they would 
actually DO it, that would be so cool, but really, it hasn't happened 
yet.

> That arrogance was also yours. You just don't like being called on it.

Would it make you happy if I agreed? Sure. I'm arrogant. I have an ego.
Maybe you just don't have time to discuss my ideas. But I notice people 
with these 'attitudes' always have time to tell me how arrogant I am. But 
they never SHOW me. They never say, "your idea is stupid because". No, 
they just say "our way is better", so by default my idea is "stupid"? LOL

> Wouldn't know about 'terrible' or anything, but your idea simply fails a 
> variation of the Occam's razor test: it's unnecessarily complicated, 
> hard to implement, harder to maintain, and non-centralized, whereas much 
> simpler, more elegant, centralized solutions are at hand.

Two thoughts on that one:

Firstly, you keep *saying* it would be 'complicated' and 'hard to 
implement', which I suppose is a little bit better than just saying 'bad', 
but not much. You don't say HOW it would be so. It has the sound of 
someone *assuming* that it would be so. I haven't bothered to contradict 
this notion, but truthfully, I wouldn't advance the idea if I didn't have 
a feeling that it *might* be easy to implement.

Secondly, and more importantly, Occam's razor is founded on the notion 
of finding the simplest solution to a given problem. Don't multiply 
entities unnecessarily. But the key word it 'necessary'. The solution must 
indeed *solve* the problem. I am reminded of the Bloom County Cartoon 
where Milo shows how he can solve all the world's energy needs with a 
porcupine and two boxes of raisin bran, and the teacher says "porcupines 
don't like raisin bran". No matter how 'good' your idea is, if some simple 
business 'priority' (like keeping clients) interferes with its adoption, 
then your solution is not *allowed* to work. Factor *that* in when 
invoking Occam. I'm facing the same conundrum right here right now. My 
idea *may* be good, but we'll never find out because this community is 
busy stomping on it rather than discussing it. So according to Occam, my 
idea is 'bad', not because it is unworkable, but because it is rejected.

> Solutions you didn't even know about. That's where your quest should 
> have started, and where this thread ought to end.

Well, this thread is going to end anyway, because according to Occam's 
logic, I can sure as asterisks tell that no one around here is really 
going to give me a serious reply. Just more of this holier-than-thou 
stuff. So with respect, I'm not reading any more. Not even sure why I'm 
sending this, except, honestly, I have a bit of an ego. Someone posts 
untruths about me, I feel compelled to correct them. Probably won't work. 
But that's my shortcoming. (weak grin)

Anyways....

- C

RE: Personal SPF

Posted by Mark <ad...@asarian-host.net>.
-----Original Message-----
From: Charles Gregory [mailto:cgregory@hwcn.org] 
Sent: dinsdag 5 mei 2009 22:40
To: users@spamassassin.apache.org
Subject: Re: Personal SPF

> > Defining personalised SPF would cause much more work and troubles for
> > users. Yes, apparently not for you.
> 
> Everything is "more work". Question is, would it be WORTH it?
> 
> > Many people responded this thread saying it's bad idea.
> 
> To date, not counting the 'take my word for it' crowd, I've had one 
> concrete suggestion on how to do it 'better', which I am implmenting.

Okay, enough with the righteous indignation already. Only several posts
ago you had never even heard of SMTP AUTH, or how folks generally solve
their roaming user problem by means of having them connect to 'submission'
port 587. So, perhaps peeps could have been nicer about your ignorance;
but the ignorance itself was squarely yours. Live with it.

Way I see it, your idea was shot down, without much ado, not because of
any alleged arrogance on 'our' end, but simply because folks like you are
a dime a dozen, these days; whether it's on the marid/asrg/whatever list,
there's always the bloke-du-jour who comes up with a 'brilliant' new,
often elaborate, plan to do things differently. And usually, like in your
case, they haven't done their homework first. A few simple google
searching would have brought you to SMTP AUTH, port 587, STARTTLS, etc.
Instead, thinking your idea was God's gift to earth, you decided to forego
on finding out how people have been solving these issues for the last ten
years. That arrogance was also yours. You just don't like being called on
it.

Wouldn't know about 'terrible' or anything, but your idea simply fails a
variation of the Occam's razor test: it's unnecessarily complicated, hard
to implement, harder to maintain, and non-centralized, whereas much
simpler, more elegant, centralized solutions are at hand. Solutions you
didn't even know about. That's where your quest should have started, and
where this thread ought to end.

- Mark


Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 5 May 2009, Matus UHLAR - fantomas wrote:
> Defining personalised SPF would cause much more work and troubles for
> users. Yes, apparently not for you.

Everything is "more work". Question is, would it be WORTH it?

> Many people responded this thread saying it's bad idea.

To date, not counting the 'take my word for it' crowd, I've had one 
concrete suggestion on how to do it 'better', which I am implmenting.

> You repeated a few times that you have no problem being wrong but 
> apparently you are not taking anyone's arguments but yours.

Give or take the fact that I am now implementing SMTP auth.... I am still 
not hearing arguments, only opinions.

> As I have already said, configuration you prefer (each user sends mail
> through its ISP's mail server)

Yo! Who the asterisks said I *prefer* it? I'm just saying its a fact of 
life we have to live with. I'm looking for the best solution that will 
work for a large world, not just me and my one setup.

> Yes, I repeat, your idea is sick, based on completely different approach 
> much (most?) of the world currently uses.

Sick. Now that's constructive. Is that a bandwidth measurement? LOL...

> - setting up PSPF for user connecting through different provider takes you
>  away verification that the sender is really the user. Only you at your
>  mailserver can validate the e-mail address.

(grasp chest - feign heart-attack) Wow! An *argument*!

Yeah, I thought of this one. Any mechanism that I can think of to easily 
automate setup would inherently introduce the possibility of forgery, 
defeating the whole point of the system.... You know, if you weren't so 
busy trying to hammer this down, you might see that I've had doubts about 
this idea from the beginning. That's why I threw it out here.

> - anyone connecting through such provider could fake the users' e-mail
>  address withot you being able to block the mail

This argument only extends by degree the current situation where someone 
could hack *my* server and send mail 'protected' by my SPF. The majority 
of spammers would still be blocked.

> I was the first one in this thread who brought up port 587.

So why switch tactics now? If you are capable of rational argument, then 
keep it up. It's more productive than just yelping 'bad, bad, bad'.

> Well, the main problem is you don't have the PSPF and I doubt anyone 
> will want it.

Again, a nice opinion, but no real sense of *why*. Inertia is not a 
reason.

> I was at the idea all problems have been made clear to you....

Frankly, I've thought of more problems on my own than anyone has mentioned 
here. But it really irks me to shelve SAV. There *must* be some 
bandwidth-friendly way to achive *that* goal....

- Charles


Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Tue, 5 May 2009, Matus UHLAR - fantomas wrote:
>> On 04.05.09 16:43, Charles Gregory wrote:
>>> Strictly speaking, getting them to use it consistently and properly will
>>> be MORE difficult,
>> more difficult than what? More difficult than discussing it here or more
>> difficult than implementing PSPF based on your sick setup and requirements?

On 05.05.09 10:32, Charles Gregory wrote:
> Less difficult than getting people to respond rationally and 
> intelligently to what I actually posted rather than grabbing a sentence 
> out of context and using it to construct a glib insult.

> I don't have a problem with being wrong. But if you think you're going to 
> 'shout me down' with arrogant pronouncements like the above, well, good  
> luck with thtat...

Defining personalised SPF would cause much more work and troubles for
users. Yes, apparently not for you.

Many people responded this thread saying it's bad idea. You repeated a few
times that you have no problem being wrong but apparently you are not taking
anyone's arguments but yours.

As I have already said, configuration you prefer (each user sends mail
through its ISP's mail server) requires changing configuration every time
they connect from different place. The configuration we are recommending
only requires setting configuration once, but correctly.

Many providers are doing the same. Any provider using SPF and/or DKIM
requires (by nature) that users send mail through their SMTP servers or
webmail. The whole point of SPF is defining mail from which domain must be
sent through which servers.

Yes, I repeat, your idea is sick, based on completely different approach
much (most?) of the world currently uses.


Want more arguments?

- setting up PSPF for user connecting through different provider takes you
  away verification that the sender is really the user. Only you at your
  mailserver can validate the e-mail address.
- anyone connecting through such provider could fake the users' e-mail
  address withot you being able to block the mail

>> internet connection is much easier than changing SMTP server every time 
>> they connect to other network.
>
> You know, at least the other posters have brought up port 587, which  
> offers a way around the standard port 25 block that stands in the way of  
> your 'easy' idea.

I was the first one in this thread who brought up port 587.
Unless the mail archive is lying or hiding something. Check yourself

>> Send the notice two or more times. They will comply when they will 
>> start getting failures and you'll be able it's because they didn't read 
>> and follow multiple
>
> Ah, I'll take a guess as to what *that* twisted syntax means. Firstly, it 
> means that you typed your message in a hurry, which reflects that you 
> just skimmed over my e-mail with equal speed, missing all the fine 
> points. You didn't really care to read my full reasoning for why I can't 
> rely on notices.

OK, sorry for misreading. I've read your message twice (to be sure what I've
understood) but apparently I've missed something.

> We may be not-for-profit, but we still have to run on 
> membership revenues, and those revenues *drop* when people decide that 
> "we have a problem" and instead of phoning us, they think the solution is 
> to go find another ISP. I've had people phone me up to cancel their 
> accounts because their e-mails "didn't work for three weeks", when they 
> had a glitch in their anti-virus that was blocking pop. You would think 
> that any reasoning human would call us for *help*. No, they just presume 
> *we* have a problem, "wait" for us to fix it, then go find another 
> provider.... Stupid. And yes, sometimes I think we'd be better off 
> without those clients, but times are tight, and no we would *not* be 
> better off. So we avoid situations where users who don't read notices 
> have any changes that can interrupt their service. So we have to have an 
> OPT-IN mechanism that at the least will get the 'PSPF' working for the 
> people smart enough to use it.

Well, the main problem is you don't have the PSPF and I doubt anyone will
want it.

I work for an ISP where we run into the same problem, but are moving towards
requiring authentication, of course we'll warn all users they need to set it
up if they haven't in the past.

Of course I know users are stupid. But trying to define whole new protocol
with certain flaws (see above and other mails, I don't like repeating clear
things over, others apparently aren't too)

However to prevent ourself from running into problems (we ran into one last)
there's no other way than to implement some "security" checks even if we
risk loosing some customers

>> Please, stop the PSPF discussions and go implement something that will
>> work without changing the whole internet
>
> LOL! Please stop discussing ideas? I would hestitate to offend any  
> particular relgion by citing a specific example, but WOW do you ever 
> sound like the worst religious leaders telling their followers what they 
> can believe or say or do.....

I was at the idea all problems have been made clear to you, I was
apparenly wrong. Here you are with new arguments again PSPF.

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name. 

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 5 May 2009, Matus UHLAR - fantomas wrote:
> On 04.05.09 16:43, Charles Gregory wrote:
>> Strictly speaking, getting them to use it consistently and properly will
>> be MORE difficult,
> more difficult than what? More difficult than discussing it here or more
> difficult than implementing PSPF based on your sick setup and requirements?

Less difficult than getting people to respond rationally and intelligently 
to what I actually posted rather than grabbing a sentence out of context 
and using it to construct a glib insult.

I don't have a problem with being wrong. But if you think you're going to 
'shout me down' with arrogant pronouncements like the above, well, good 
luck with thtat...

> Configuring the mail account in their MUA independently on their 
> internet connection is much easier than changing SMTP server every time 
> they connect to other network.

You know, at least the other posters have brought up port 587, which 
offers a way around the standard port 25 block that stands in the way of 
your 'easy' idea.

> Send the notice two or more times. They will comply when they will start 
> getting failures and you'll be able it's because they didn't read and 
> follow multiple

Ah, I'll take a guess as to what *that* twisted syntax means. Firstly, it 
means that you typed your message in a hurry, which reflects that you just 
skimmed over my e-mail with equal speed, missing all the fine points. You 
didn't really care to read my full reasoning for why I can't rely on 
notices. We may be not-for-profit, but we still have to run on membership 
revenues, and those revenues *drop* when people decide that "we have a 
problem" and instead of phoning us, they think the solution is to go find 
another ISP. I've had people phone me up to cancel their accounts because 
their e-mails "didn't work for three weeks", when they had a glitch in 
their anti-virus that was blocking pop. You would think that any reasoning 
human would call us for *help*. No, they just presume *we* have a problem, 
"wait" for us to fix it, then go find another provider.... Stupid. And 
yes, sometimes I think we'd be better off without those clients, but times 
are tight, and no we would *not* be better off. So we avoid situations 
where users who don't read notices have any changes that can interrupt 
their service. So we have to have an OPT-IN mechanism that at the least 
will get the 'PSPF' working for the people smart enough to use it.

>> (nod) That would be one of the technical hurdles of this. Each ISP would
>> need a published PSPF Server record identifying all *possible* outbound
>> mail servers that any connected client could use, and then someone
>> setting up their PSPF would use a 'lookup' function to get that
>> information, and paste it into the opt-in form for the host serving their
>> domain name.
> <irony>
> Now this is really much easier than configure mail user agents properly.
> </irony>

If there was even the faintest chance that your suggestion achieved all 
(or most of) the objectives outlined in my proposal, I might accept your 
stupid attempt at sarcasm as a clever argument. But you haven't come close 
to addressing the 'replacement for SMTP callback' aspect of the
discussion...

Me, I posed a question. I *don't* have all the facts. Thank you, but I 
want help from people who know MORE than me. There are lots of them on 
here, and they are really helpful. Thanks to them, I've disabled my SMTP 
callbacks. Good reasoned argument always wins. Try it sometime.

> You forgot to mention the users will change their PSPF every time they 
> start/stop using other connection, at home, work, coffee shop, weekend 
> house etc etc etc.

<my turn at sarcasm>
Oh.... My.... Deity..... I hadn't thought of that! Why, this would be an 
incredibly difficult hurdle to overcome!
<end sarcasm>

I'm a programmer. I make a living turning incredibly difficult things into 
simple push-one-button solutions. I can make it easy for my users. What I 
can't do is make it load-efficient on the internet. So THAT is what is up 
for discussion here.

> Please, stop the PSPF discussions and go implement something that will
> work without changing the whole internet

LOL! Please stop discussing ideas? I would hestitate to offend any 
particular relgion by citing a specific example, but WOW do you ever sound 
like the worst religious leaders telling their followers what they can 
believe or say or do.....

> "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

I take it back. You *have* mastered irony.

- Charles

Re: Personal SPF

Posted by Jonas Eckerman <jo...@frukt.org>.
Matus UHLAR - fantomas <uh...@fantomas.sk> 5.5.'09,  8:55:

> > Strictly speaking, getting them to use it consistently and properly will  
> > be MORE difficult,

> more difficult than what?

I parsed it as him stating that getting users to use his proposed PSPF will be more difficult than getting them to use athenticated SMTP to his servers.

/Jonas


Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Mon, 4 May 2009, Jonas Eckerman wrote:
>> Why do you think it would be easier to get those of your users that 
>> send through other servers to publish a personal SPF record with 
>> correct information about the external IP address of the outgoing relay 
>> they use than it would be to get then to use SMTP auth with your 
>> servers?

On 04.05.09 16:43, Charles Gregory wrote:
> Strictly speaking, getting them to use it consistently and properly will  
> be MORE difficult,

more difficult than what? More difficult than discussing it here or more
difficult than implementing PSPF based on your sick setup and requirements?

Configuring the mail account in their MUA independently on their internet
connection is much easier than changing SMTP server every time they connect
to other network.

> but unlike SMTP auth, there is nothing I need enforce  
> on all users at once, and the default condition is a 'neutral' result.  
> PSPF=NONE. Anyone who doesn't get the e-mail notice (or ignores it) will  
> continue as usual.

Send the notice two or more times. They will comply when they will start
getting failures and you'll be able it's because they didn't read and follow
multiple 

> (nod) That would be one of the technical hurdles of this. Each ISP would  
> need a published PSPF Server record identifying all *possible* outbound  
> mail servers that any connected client could use, and then someone 
> setting up their PSPF would use a 'lookup' function to get that 
> information, and paste it into the opt-in form for the host serving their 
> domain name.

<irony>
Now this is really much easier than configure mail user agents properly.
</irony>

You forgot to mention the users will change their PSPF every time they
start/stop using other connection, at home, work, coffee shop, weekend house
etc etc etc.

Please, stop the PSPF discussions and go implement something that will
work without changing the whole internet

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Mon, 4 May 2009, Jonas Eckerman wrote:
> Why do you think it would be easier to get those of your users that send 
> through other servers to publish a personal SPF record with correct 
> information about the external IP address of the outgoing relay they use than 
> it would be to get then to use SMTP auth with your servers?

Strictly speaking, getting them to use it consistently and properly will 
be MORE difficult, but unlike SMTP auth, there is nothing I need enforce 
on all users at once, and the default condition is a 'neutral' result. 
PSPF=NONE. Anyone who doesn't get the e-mail notice (or ignores it) will 
continue as usual. Naturally, this means that the effectiveness of the
query will be less at first. :)

> How many users have any idea at all about the external IPs of their ISPs 
> mail relays?

(nod) That would be one of the technical hurdles of this. Each ISP would 
need a published PSPF Server record identifying all *possible* outbound 
mail servers that any connected client could use, and then someone setting 
up their PSPF would use a 'lookup' function to get that information, and 
paste it into the opt-in form for the host serving their domain name.

> How many of the users who do have a good idea about the external IPs of 
> their ISPs mail relays have no idee how to tell their mail client to 
> send using use authenticated SMTP with your servers?

Presumably the burden of instruction will fall on ME. But again, those 
instructions need to be *read*. So the default condition for someone who 
ignores that settings would be to have their address treated as PSPF:None.

> I might just be confused, but to me it seems that your solution requires 
> more from your users, not less.

Yes, it requires a bit more. But for that effort, we also get a mechanism 
that when queried will serve the purpose of "SMTP callback", without the 
expensive SMTP trasnactions (and DDOS possibilities).

> And, even if (big, big if) the big mail receivers (Yahoo, Google, big ISPs, 
> etc) does eventuelly support your personal SPF, it'll take years until it 
> becomes effective.

(nod) And, as I asked at the beginning of this thread, we would have to 
decide if there is a sufficiently large proportion of addresses not 
already covered by standard SPF that would benefit from this idea, and 
whether the 'extra' hits on DNS (and caching) would be too heavy.
I'm not too sure of this idea myself, but its simple ideal has benefits,
so I figure its worth tossing around.... :)

- Charles


Re: Personal SPF

Posted by Jonas Eckerman <jo...@frukt.org>.
Charles Gregory wrote:

>>> Proposal: "Personal SPF" - A DNS-based lookup system to allow individual
>>> sender's of e-mail to publish a *personal* SPF record within the context
>>> of their domain's SPF records, that would identify an IP or range of 
>>> IP's which they would be 'stating' are the only possible sources of their
>>> mail.

> The only other possible work-around for this is to enforce a 'hard' SPF 
> and establish 'pop before SMTP' or 'SMTP auth' protocols, then spam our 
> membership informing them that use of our server is mandatory. But that 
> would cause problems, because we don't really know *who* is using third 
> party servers, and too many of them wouldn't read the notice... :(

Why do you think it would be easier to get those of your users that send 
  through other servers to publish a personal SPF record with correct 
information about the external IP address of the outgoing relay they use 
than it would be to get then to use SMTP auth with your servers?

How many users have any idea at all about the external IPs of their ISPs 
mail relays?

How many of the users who do have a good idea about the external IPs of 
their ISPs mail relays have no idee how to tell their mail client to 
send using use authenticated SMTP with your servers?

I might just be confused, but to me it seems that your solution requires 
more from your users, not less.

And, even if (big, big if) the big mail receivers (Yahoo, Google, big 
ISPs, etc) does eventuelly support your personal SPF, it'll take years 
until it becomes effective.

Regards
/Jonas

> 
> But if we had a 'personal' system, then for as many members as we reach 
> (who pay attention to notices), we could them 'opt-in' to a voluntary "I 
> only send my mail from here" type of system, and then that would at 
> least provide *some* address protection/confirmation.
> 
>> Do they all have static IP addresses or do you imply allow users from 
>> dynamic addresses to send mail directly?
> 
> As noted above, we can control our (dynamic) dialups, but not third 
> party usage. So effectively, anyone, anywhere, can use an hwcn.org 
> return address. This is something I'd really like to limit to legitimate 
> users
> without enforcing use of our mail server only (though I realize this may 
> be the best long term solution for us).
> 
> OF course, my suggestion also hinges on whether there are a sufficient 
> number of other systems out there in a similar 'position' as us, who 
> would also benefit from this 'next level' of SPF verification...
> 
> - Charles


-- 
Jonas Eckerman
Fruktträdet & Förbundet Sveriges Dövblinda
http://www.fsdb.org/
http://www.frukt.org/
http://whatever.frukt.org/

Re: [SA] Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> Matus UHLAR - fantomas wrote:
> >> On Mon, 4 May 2009, LuKreme wrote:
> >>> This is what port 587 is *for*. This is what SASL authentication is *for*.
> > 
> > On 05.05.09 09:25, Charles Gregory wrote:
> >> Hmmmm. Quick (dumb) question. If I tell my users to click the little 
> >> check box in a mail client (Outlook Express or Thunderbird) that says 
> >> "use SMTP authentication", does it automatically switch to port 587, or 
> >> do I need to tell my users how/where to change the port number?
> > 
> > you need the latter.
> > Outlook users may want to use port 465 with non-negotiated SSL.

On 05.05.09 10:45, Adam Katz wrote:
> Funny thing about that; 465 is a non-standard SSL-requiring port for
> SMTP, chosen by Microsoft.  Despite that, Micorosft Outlook (2003+ at
> least) does *not* change the port from 25 when you specify SSL while
> Mozilla Thunderbird will change it to 465.  No configuration on either
> will use 587.

That's because M$ Outlook supports negotiating TLS only on port 25.
On any other port it only supports SSL (non-negotiated) or plaintect. That's
why I recommend (and we do) support port 465.

(I don't remember which outlook version I've been testing, but I remember
the result).

I don't have ay informations that it's microsoft who selected 465 for
smtps, but that's not issue since it looks being widely accepted...

> The official recommendation is to require port 587 and require
> authentication over TLS, but until programs default to using it in
> some capacity, it just seems like a bad idea:
> 
> Users are not smart.  Give them the simplest options.
> 
> Use different servers for MX vs outbound SMTP, and for the latter,
> implement all three ports (25 and 587 requiring STARTTLS and
> authentication, 465 being SSL-wrapped and requiring authentication).

We do that. However, we plan to migrate all users to 587/465 to prevent from
problems if anyone would block 25 (and so we could do that if anything
happens, some users don't need/have to delive mail directly)
 
> If you open SMTP like that, you should probably also have something
> connected to your firewall (e.g. fail2ban for Linux) that will drop
> all connections to mail relays that stubbornly try to connect, or at
> least have the SMTP server configured to do something similar.

I haven't noticed any such problem.
-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot. 

Re: [SA] Personal SPF

Posted by Adam Katz <an...@khopis.com>.
Matus UHLAR - fantomas wrote:
>> On Mon, 4 May 2009, LuKreme wrote:
>>> This is what port 587 is *for*. This is what SASL authentication is *for*.
> 
> On 05.05.09 09:25, Charles Gregory wrote:
>> Hmmmm. Quick (dumb) question. If I tell my users to click the little 
>> check box in a mail client (Outlook Express or Thunderbird) that says 
>> "use SMTP authentication", does it automatically switch to port 587, or 
>> do I need to tell my users how/where to change the port number?
> 
> you need the latter.
> Outlook users may want to use port 465 with non-negotiated SSL.

Funny thing about that; 465 is a non-standard SSL-requiring port for
SMTP, chosen by Microsoft.  Despite that, Micorosft Outlook (2003+ at
least) does *not* change the port from 25 when you specify SSL while
Mozilla Thunderbird will change it to 465.  No configuration on either
will use 587.

The official recommendation is to require port 587 and require
authentication over TLS, but until programs default to using it in
some capacity, it just seems like a bad idea:

Users are not smart.  Give them the simplest options.

Use different servers for MX vs outbound SMTP, and for the latter,
implement all three ports (25 and 587 requiring STARTTLS and
authentication, 465 being SSL-wrapped and requiring authentication).

In postfix's master.cf, this would be (at the least):

smtp      inet  n       -       -       -       -       smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
submission inet n       -       -       -       -       smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

For non-Debian/non-FreeBSD systems, it may also require changing
/etc/services so that the only "465/tcp" line it contains is:

ssmtp           465/tcp         smtps           # SMTP over SSL


If you open SMTP like that, you should probably also have something
connected to your firewall (e.g. fail2ban for Linux) that will drop
all connections to mail relays that stubbornly try to connect, or at
least have the SMTP server configured to do something similar.

Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Mon, 4 May 2009, LuKreme wrote:
>> This is what port 587 is *for*. This is what SASL authentication is *for*.

On 05.05.09 09:25, Charles Gregory wrote:
> Hmmmm. Quick (dumb) question. If I tell my users to click the little 
> check box in a mail client (Outlook Express or Thunderbird) that says 
> "use SMTP authentication", does it automatically switch to port 587, or 
> do I need to tell my users how/where to change the port number?

you need the latter.
Outlook users may want to use port 465 with non-negotiated SSL.

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Mon, 4 May 2009, LuKreme wrote:
> This is what port 587 is *for*. This is what SASL authentication is *for*.

Hmmmm. Quick (dumb) question. If I tell my users to click the little check 
box in a mail client (Outlook Express or Thunderbird) that says "use SMTP 
authentication", does it automatically switch to port 587, or do I need to 
tell my users how/where to change the port number?

  - C


Re: Personal SPF

Posted by LuKreme <kr...@kreme.com>.
On 4-May-2009, at 09:40, Charles Gregory wrote:
> Yes, but also that the user must be connected to our dialup to gain  
> 'relay' access to our mail server. If someone, even one of our legit  
> users, is on a DSL connection, then they *cannot* send mail through  
> our server. They must use the server connected to their third party  
> service.

THIS is your problem.

> Good anti-spam measure, but not SPF-friendly....


No, this is not a 'good anti-spam measure' it is a 'screw your users'  
policy. If you have mail accounts for users who are not on your  
network then you have an obligation to allow those users access to  
your mailserver. Fix your server, setup SPF, and your self-created  
'problems' will go away.

This is what port 587 is *for*. This is what SASL authentication is  
*for*.


-- 
Charlie don't surf!


Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Mon, 4 May 2009, Matus UHLAR - fantomas wrote:
>> OUR mail server *requires* that a user be connected via our dialups.
> what do you mean? Users connected by your dialups can only be connected to
> your mail server?

Yes, but also that the user must be connected to our dialup to gain 
'relay' access to our mail server. If someone, even one of our legit 
users, is on a DSL connection, then they *cannot* send mail through our 
server. They must use the server connected to their third party service.
Good anti-spam measure, but not SPF-friendly....

>> And as far as I am aware, the NAS does not permit direct port 25 access
>> to any other server.
> The mail can be sent using other ports....

That's not the point being addressed - I meant only that our users could 
not send mail directly from a dynamic IP to outside mail servers... They 
are required to use ours from the dialups. So even if I could just somehow 
'separate' the two groups and SPF check those addresses, it would be 
better than no SPF check at all.... OF course, the user would still have 
to opt-in. How would I know if they didn't use alternative access 
occasionally...?

>> would cause problems, because we don't really know *who* is using third
>> party servers, and too many of them wouldn't read the notice... :(
> I don't see this a problem, since all those mailboxes are hosted on your
> machines, it shouldn't be hard to notice all customers that they MUST send
> mail from domains hosted on your servers using your servers.

Sending notice: Easy. Getting them to READ it: Hard. Having them complain, 
blame us or dump our service because it "doesn't work" without even 
giving us the chance to explain their error (because they were too 
stupid to read the notice): inevitable.

So, presuming that arguments for the 'need' are upheld, I am more 
interested in the technical questions I posed. Is it 'workable? Would it
be able to also serve as a form of sender callback, without the nasty 
DDOS risk and other drawbacks of straight SMTP callback? Or would this 
bloat DNS caching ridiculously?

- Charles

Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> On 30.04.09 14:24, Charles Gregory wrote:
>>> Proposal: "Personal SPF" - A DNS-based lookup system to allow individual
>>> sender's of e-mail to publish a *personal* SPF record within the context
>>> of their domain's SPF records, that would identify an IP or range of IP's
>>> which they would be 'stating' are the only possible sources of their
>>> mail.
>>>
>>> Why 'personal'? Because I run an ISP where user's *may* send their mail
>>> via any number of DSL connections, so I can't publish 'positive' SPF
>>> records for our whole domain.

> On Mon, 4 May 2009, Matus UHLAR - fantomas wrote:
>> Do you allow any user to send mail as any user, without need of
>> authentication on your mailserver? Even if you run their
>> mailboxes/addresses?

On 04.05.09 10:31, Charles Gregory wrote:
> OUR mail server *requires* that a user be connected via our dialups.

what do you mean? Users connected by your dialups can only be connected to
your mail server? I know some ISPs do that and quite agree with that.
Especially for dynamically-allocated IPS (some people prefer not to reject
such mail and then comply).

> And as far as I am aware, the NAS does not permit direct port 25 access  
> to any other server.

The mail can be sent using other ports, 587 is well defined for mail
submission and 465 can be user for the same reason (with SSL) as my company
does. However submitting mail via other ports should require authentication,
and if anyone does not, it's completely their problem.

> 100% secure and traceable. Our problem, which  
> prevents ordinary SPF, is that some of our users have third-party access  
> (DSL or cable) and use that company's mail server to send mail, but with  
> an hwcn.org return address.

> The only other possible work-around for this is to enforce a 'hard' SPF  
> and establish 'pop before SMTP' or 'SMTP auth' protocols, then spam our  
> membership informing them that use of our server is mandatory. But that  
> would cause problems, because we don't really know *who* is using third  
> party servers, and too many of them wouldn't read the notice... :(

I don't see this a problem, since all those mailboxes are hosted on your
machines, it shouldn't be hard to notice all customers that they MUST send
mail from domains hosted on your servers using your servers. That's
requirement when implementing anti-forgery tools like SPF/DKIM and many
hostings enforce that (by publishing SPF/DKIM records and resufing mail
from: such domains).

>> Do they all have static IP addresses or do you imply allow users from  
>> dynamic addresses to send mail directly?
>
> As noted above, we can control our (dynamic) dialups, but not third party 
> usage. So effectively, anyone, anywhere, can use an hwcn.org return  
> address. This is something I'd really like to limit to legitimate users
> without enforcing use of our mail server only (though I realize this may  
> be the best long term solution for us).

I'm afraid that enforcing your servers for hosted domains is the only way
how to use SPF/DKIM. Per-user SPF is imho an overkill

> OF course, my suggestion also hinges on whether there are a sufficient  
> number of other systems out there in a similar 'position' as us, who 
> would also benefit from this 'next level' of SPF verification...

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #99999: Out of error messages.

Re: Personal SPF

Posted by Charles Gregory <cg...@hwcn.org>.
On Mon, 4 May 2009, Matus UHLAR - fantomas wrote:
> On 30.04.09 14:24, Charles Gregory wrote:
>> Proposal: "Personal SPF" - A DNS-based lookup system to allow individual
>> sender's of e-mail to publish a *personal* SPF record within the context
>> of their domain's SPF records, that would identify an IP or range of IP's
>> which they would be 'stating' are the only possible sources of their
>> mail.
>>
>> Why 'personal'? Because I run an ISP where user's *may* send their mail
>> via any number of DSL connections, so I can't publish 'positive' SPF
>> records for our whole domain.
>
> Do you allow any user to send mail as any user, without need of
> authentication on your mailserver? Even if you run their
> mailboxes/addresses?

OUR mail server *requires* that a user be connected via our dialups.
And as far as I am aware, the NAS does not permit direct port 25 access 
to any other server. 100% secure and traceable. Our problem, which 
prevents ordinary SPF, is that some of our users have third-party access 
(DSL or cable) and use that company's mail server to send mail, but with 
an hwcn.org return address.

The only other possible work-around for this is to enforce a 'hard' SPF 
and establish 'pop before SMTP' or 'SMTP auth' protocols, then spam our 
membership informing them that use of our server is mandatory. But that 
would cause problems, because we don't really know *who* is using third 
party servers, and too many of them wouldn't read the notice... :(

But if we had a 'personal' system, then for as many members as we reach 
(who pay attention to notices), we could them 'opt-in' to a voluntary "I 
only send my mail from here" type of system, and then that would at least 
provide *some* address protection/confirmation.

> Do they all have static IP addresses or do you imply allow users from 
> dynamic addresses to send mail directly?

As noted above, we can control our (dynamic) dialups, but not third party 
usage. So effectively, anyone, anywhere, can use an hwcn.org return 
address. This is something I'd really like to limit to legitimate users
without enforcing use of our mail server only (though I realize this may 
be the best long term solution for us).

OF course, my suggestion also hinges on whether there are a sufficient 
number of other systems out there in a similar 'position' as us, who would 
also benefit from this 'next level' of SPF verification...

- Charles

Re: Personal SPF

Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 30.04.09 14:24, Charles Gregory wrote:
> Proposal: "Personal SPF" - A DNS-based lookup system to allow individual  
> sender's of e-mail to publish a *personal* SPF record within the context  
> of their domain's SPF records, that would identify an IP or range of IP's 
> which they would be 'stating' are the only possible sources of their 
> mail.
>
> Why 'personal'? Because I run an ISP where user's *may* send their mail  
> via any number of DSL connections, so I can't publish 'positive' SPF  
> records for our whole domain.

Do you allow any user to send mail as any user, without need of
authentication on your mailserver? Even if you run their
mailboxes/addresses?

Do they all have static IP addresses or do you imply allow users from
dynamic addresses to send mail directly? 

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]