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 <alpine.lrh.2.00.0904301351030.23...@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.
--
