In article <cistron.5ED9A06E-DA3E-11D7-B146-00039388672E@muada.com>,
>But how about this: in addition to MX hosts, every domain also has one
>or more MO (mail originator) hosts. Mail servers then get to check the
>address of the SMTP server they're talking to against the DNS records
>for the domain in the sender's address. Then customers who use an email
>address under their ISP's domain have to use the ISP's relay, while
>people with their own (sub) domain get to use their own.
I travel around. I read my email by POP3/IMAP, I use local ISP's SMTP
server for outgoing - surely that means I can't use my own domain for
email?
Simon
Time to switch to SMTP AUTH and use the same relay always.
[Note: I posted something else on this topic, but it doesn't appear to have
made it through yet...]
I travel around. I read my email by POP3/IMAP, I use local ISP's SMTP
server for outgoing - surely that means I can't use my own domain for
email?
Your ISP should support SMTP_AUTH with TLS for you. You would continue to use their mail servers no matter where you are or how you are connected to the Internet.
-Matt
Either the webmail solution meets your needs, or you need to obtain service from a company that offers a solution that meets your needs. Why is this so hard to understand?
jc
You switch service provider or give them a whack with the cluebat.
And if the "service provider" is your employer/educational institution? You
quit your job? Drop out of school? Swallow your pride and suffer with
webmail?
Vivien
Mikael Abrahamsson wrote:
You switch service provider or give them a whack with the cluebat.
Some providers don't support auth do to the insecure passwords their users have. Having your server opened up to relay spam because your user had a bad password is not a good prospect.
-Jack
You switch service provider or give them a whack with the cluebat.
And if the "service provider" is your employer/educational institution? You
quit your job? Drop out of school? Swallow your pride and suffer with
webmail?
Spend $19.95 getting a dialup account for an ISP with a clue and use their mail servers. If employed charge the $20/month on your expense report.
You seem to be misunderstanding the issue. Let's say you work at
someplace.edu. You want to send mail from home. With the SPF-type schemes
being discussed, your mail MUST come from someplace.edu's server.
If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your
dialup account will let you use the dialup ISP's mail server... But your
mail will get bounced because it's not something from someplace.edu.
Hence, if no SMTP AUTH relay, you're screwed.
Vivien
You do the same thing you do when they implement other stupid policies - you live with the policy, or you work around it. If your school makes a stupid policy that you can't park your car between the hours of 8 am and 9 am, you get there before 8 or after 9, or you have a friend drop you off, or take the bus, or you pay to park in the lot across the street.
jc
Because you're not understanding the issue... If you get an email account
from your employer/educational institution/etc and have to access it from
home and send mail from it, you can't "obtain service from a company that
offers a solution that meets your needs." If you can't convince your admins
(and good luck if you don't work in the IT department) that they need to set
up SMTP AUTH, then you are screwed... Get used to dialing into your
employer/educational institution/etc's network to do email, simply to comply
with these things, or hello webmail. And how will you explain to people who
quite happily have their POP3 clients set up to get mail from their work's
POP3 server, and SMTP to their local ISP that suddenly they can't do it that
way anymore?
If this solution had been implemented 5 years ago instead of the "no third
party relays" system now in place, I wouldn't be opposed to it... But the
issue is that the "use the local SMTP server to send" model is the main one
deployed in the field today, and if you start staying NOW that mail must be
relayed through a domain's particular SMTP server and that server doesn't
support SMTP AUTH relaying, you're now screwed...
Vivien
So the provider allows the user to pick an insecure password, and then
complains that they can't support a security measure because of their poor
policy choices/enforcement?
Hey Mikael, hand me that cluebat......
You seem to be misunderstanding the issue. Let's say you work at
someplace.edu. You want to send mail from home. With the SPF-type schemes
being discussed, your mail MUST come from someplace.edu's server.If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your
dialup account will let you use the dialup ISP's mail server... But your
mail will get bounced because it's not something from someplace.edu.Hence, if no SMTP AUTH relay, you're screwed.
Port forward 127.0.0.1:25 through to someplace.edu:25 using SSH. Or VPN. Or ...
More than one way to skin this cat.
-matt
If you have a shell account on someplace.edu, yes, I agree, that's probably
the best way (and if anyone looks at the headers of this message, that's how
I've been doing SMTP for like three years now... Too lazy to set up SMTP
AUTH somewhere where I'm the admin).
But if you have no shell account, or you're not technologically clueful,
you're still hopeless... So, the conclusion still seems to be that SPF and
such things will break your email, unless
i) SMTP AUTH is available
ii) You're sufficiently clueful (and required things like VPN, SSH, etc are
available) that you can implement a workaround.
Vivien
JC Dill wrote:
Either the webmail solution meets your needs, or you need to obtain service from a company that offers a solution that meets your needs. Why is this so hard to understand?
Or people implement a protocol that doesn't break existing uses of the system (let's not forget the issues with many mailing-lists and .forward files).
Personally, I like the idea of verifying that an IP address that is sending mail is allowed to send mail according to domain X, which is either verified by the mail from rhs or by the (he|eh)lo parameter. One or the other should be able to be verified; mail from rhs when at the home network and (he|eh)lo parameter at remote sites. Checking the MX records for each would make a good portion of the current mail servers compliant (except those with seperate outbound/inbound servers) and having a different tag (txt, new DNS record, special dns tag like outmail.fqdn) would allow outbound only servers to quickly meet compliance.
It's quicker and more simplistic than any proposal I've read. It doesn't break anonymous forwarding or sending mail through other provider's smtp servers. What it does do is verify that someone is responsible for that mail connection and that someone is domain X without arguement.
I don't care if envelopes appear to be forged. It's done regularly in production. What I do care about is being able to say that someone is responsible for the email. If domain X said that a server can send mail outbound and it's not the mail I wanted, holder of domain X is liable and lawyers can do the dirty work they are paid for. Or at a minimum, I can block domain X and not feel bad about it.
-Jack
You have an easy way to change password enforcement of an existing user base? Dealing with people infected with the latest worms has increased workloads across the board. That's only a small percentage of the user base. Password enforcement on an existing user base will cause problems for a majority of the user base.
Proprietary dialers help, but have their own problems. If you use the mail interface to change the dialup passwords, you'll get calls from users that can no longer dial in; otherwise you fragment passwords on an account and add overhead that's unnecessary. Adding the policy and waiting for it to rotate out would take over a decade.
I wouldn't recommend a policy change like that for any user base over 10,000.
-Jack
So you're saying that because you've got too many users with dumb passwords,
that's justification for not fixing it? 
/Valdis (and yes, we're in the middle of a multi-month deployment of better password
policies for some 40K entities, so been there, done that)
Quoting "Vivien M." <vivienm@dyndns.org>:
You seem to be misunderstanding the issue. Let's say you work at
someplace.edu. You want to send mail from home. With the SPF-type schemes
being discussed, your mail MUST come from someplace.edu's server.If someplace.edu won't set up an SMTP AUTH relay, what do you do? Your
dialup account will let you use the dialup ISP's mail server... But your
mail will get bounced because it's not something from someplace.edu.Hence, if no SMTP AUTH relay, you're screwed.
If someplace.edu understands the the basic idea being discussed, one might
assume that they wouldn't implement Jim Miller's idea until they've implemented
SMTP AUTH (or POP before SMTP) as well. If they don't know about / know how to
implement SMTP AUTH, they probably wouldn't bother to make the proper DNS
changes to make this idea work. One might also assume that if the MTA used by
someplace.edu implements Jim Miller's idea, said MTA is also is modern enough to
have support for SMTP AUTH. You may find those to be doubious assumptions, but I
don't think they're that unreasonable.
The only weakness I see is that spammers could find a domain that doesn't
implement Jim Miller's idea and forge mail in their name instead. So what if
hotmail.com implements the system? There are 100 million other domain names the
spammers could pick from. It's not a solution. It will slow the spammers down.
It will inconvenience them. It won't stop them. That doesn't mean it shouldn't
be done... just that it's not a panacea, and might not even be that effective.
(I wonder if I would get less SPAM if every SMTP server were still an open relay.)
By the way, a strengh of this idea that I haven't seen discussed here is that
such a system would cut down on the spread (and worthless bounce reports) of
current viruses that forge the From: header.
-Adam