In article <cistron.5ED9A06E-DA3E-11D7-B146-00039388672E@muada.com>, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
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.
Google for "RMX DNS". There's a few other proposals too; see for example http://spf.pobox.com/ Mike. -- RAND USR 16514
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 -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: Simon.Lockhart@bbc.co.uk | id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
On Fri, 29 Aug 2003, Simon Lockhart wrote:
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?
Time to switch to SMTP AUTH and use the same relay always. -- Mikael Abrahamsson email: swmike@swm.pp.se
[Note: I posted something else on this topic, but it doesn't appear to have made it through yet...]
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mikael Abrahamsson Sent: August 29, 2003 3:20 PM To: nanog@merit.edu Subject: Re: Fun new policy at AOL
On Fri, 29 Aug 2003, Simon Lockhart wrote:
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?
Time to switch to SMTP AUTH and use the same relay always.
And what do you do if you're not the admin for the relay? And what about if the admin tells you "This is why we installed some webmail package. Use that instead."? Vivien -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
At 12:32 PM 8/29/2003, Vivien M. wrote:
Time to switch to SMTP AUTH and use the same relay always.
And what do you do if you're not the admin for the relay? And what about if the admin tells you "This is why we installed some webmail package. Use that instead."?
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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of JC Dill Sent: August 29, 2003 3:43 PM To: nanog@merit.edu Subject: RE: Fun new policy at AOL
At 12:32 PM 8/29/2003, Vivien M. wrote:
Time to switch to SMTP AUTH and use the same relay always.
And what do you do if you're not the admin for the relay? And what about if the admin tells you "This is why we installed some webmail package. Use that instead."?
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?
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 -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
On Fri, Aug 29, 2003 at 04:08:52PM -0400, Vivien M. wrote:
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...
If spam was as rampant 5 years ago, perhaps this would be in place. Change sucks, doesn't it.
On Fri, 29 Aug 2003, Omachonu Ogali wrote:
On Fri, Aug 29, 2003 at 04:08:52PM -0400, Vivien M. wrote:
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...
If spam was as rampant 5 years ago, perhaps this would be in place.
Change sucks, doesn't it.
It really doesnt make any difference, if you change the rules by implementing auth etc the spammers will just adopt and it follows that the more thorough you are in the anti-spam measures, the more drastic the spammers will become to maintain their business.. Steve
On Sat, Aug 30, 2003 at 12:21:02PM +0100, Stephen J. Wilcox wrote:
It really doesnt make any difference, if you change the rules by implementing auth etc the spammers will just adopt and it follows that the more thorough you are in the anti-spam measures, the more drastic the spammers will become to maintain their business..
Yes, it does make a difference. a) Now, there is no longer a gray area with spam, if they are successfully bruteforcing your users' passwords, I believe that falls under unauthorized entry (now, there is no need to go to your senator to ASK them to put anti-spam laws in place), and you can follow this up with your local law enforcement agency. b) This adds an extra step, therefore slowing down their dictionary attacks and relay abuse, resulting in a lot LESS spam. c) I'm also asking for server-to-server authentication among trusted mail servers and administrators, at which point you can ask the other mail server to sign a contract laying out the terms of sending mail to your server (and they can do the same to you) and make them legally liable for any breaches. Hey, now you can actally implement those per message fines in all of your AUPs. d) After reptitive breaches, I'm sure users and administrators would be willing to chip into a lawyer pot (kinda like ISPC) which would make it easier to sue offenders rather than asking themselves "is it really worth it to plunk down $10k for some penis enlargement mail". Think of something along the lines of USENET peering, but now with SMTP.
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
On Fri, 29 Aug 2003, Vivien M. wrote:
And what do you do if you're not the admin for the relay? And what about if the admin tells you "This is why we installed some webmail package. Use that instead."?
You switch service provider or give them a whack with the cluebat. -- Mikael Abrahamsson email: swmike@swm.pp.se
-----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: August 29, 2003 3:44 PM To: Vivien M. Cc: nanog@merit.edu Subject: RE: Fun new policy at AOL
On Fri, 29 Aug 2003, Vivien M. wrote:
And what do you do if you're not the admin for the relay? And what about if the admin tells you "This is why we installed some webmail package. Use that instead."?
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 -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
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.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Matthew Crocker Sent: August 29, 2003 3:58 PM To: Vivien M. Cc: 'Mikael Abrahamsson'; nanog@merit.edu Subject: Re: Fun new policy at AOL
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 -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.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.
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
-----Original Message----- From: Matthew Crocker [mailto:matthew@crocker.com] Sent: August 29, 2003 4:16 PM To: Vivien M. Cc: 'Mikael Abrahamsson'; nanog@merit.edu Subject: Re: Fun new policy at AOL
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.
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 -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
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
On Fri, Aug 29, 2003 at 04:04:42PM -0400, Vivien M. wrote:
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.
Did I miss the obvious? This is not a technical issue. You have presented a case where one lacks the (free) resources needed to perform one's job. This is something you take up with your manager. "I could easily do this part during my off hours, it just requires the mail server admin to setup (free) SMTP AUTH s/w to limit access to us employees." If not, the company policy is not to do work during off-hours. It can wait until you get in the next business day. (Note that policy here is defined by the actual behavior, not the statement of policy, which can be wrong)
Hence, if no SMTP AUTH relay, you're screwed.
Sure. And if they throw the (power) circuit breakers at work, none of my computers work (for long) either. That's not a limitation of the grid. -- Ray Wong rayw@rayw.net
At 12:45 PM 8/29/2003, Vivien M. wrote:
On Fri, 29 Aug 2003, Vivien M. wrote:
And what do you do if you're not the admin for the relay? And what about if the admin tells you "This is why we installed some webmail package. Use that instead."?
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?
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
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
On Fri, 29 Aug 2003 14:47:50 CDT, Jack Bates said:
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.
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......
Valdis.Kletnieks@vt.edu wrote:
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?
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
On Fri, 29 Aug 2003 16:19:28 CDT, Jack Bates said:
I wouldn't recommend a policy change like that for any user base over 10,000.
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)
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
Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: Simon.Lockhart@bbc.co.uk | id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
participants (12)
-
Adam Kujawski -
Jack Bates -
JC Dill -
Matthew Crocker -
Mikael Abrahamsson -
Miquel van Smoorenburg -
Omachonu Ogali -
Ray Wong -
Simon Lockhart -
Stephen J. Wilcox -
Valdis.Kletnieks＠vt.edu -
Vivien M.