Re: Personal SPF
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
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 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? Be
Re: [sa] RE: Personal SPF
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
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
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
Re: Personal SPF
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
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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
Matus UHLAR - fantomas 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
-Original Message- From: Charles Gregory [mailto:cgreg...@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
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
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
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
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
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
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
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
> 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 thei
Re: Personal SPF
> 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, uh...@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: [SA] Personal SPF
> 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: > >> H. 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, uh...@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: Personal SPF
>> 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, uh...@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
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: [SA] Personal SPF
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: >> H. 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
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
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. Now this is really much easier than configure mail user agents properly. 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. Oh My Deity. I hadn't thought of that! Why, this would be an incredibly difficult hurdle to overcome! 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
> 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: > H. 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, uh...@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
On Mon, 4 May 2009, LuKreme wrote: This is what port 587 is *for*. This is what SASL authentication is *for*. H. 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
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
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
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
> 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. Now this is really much easier than configure mail user agents properly. 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, uh...@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
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
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
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: Personal SPF
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
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
>> 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, uh...@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 #9: Out of error messages.
Re: Personal SPF
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, uh...@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]
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
