Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 13 Aug 2004 at 8:41, Steffen Kaiser wrote: > > It's an optional part of SMTP that doesn't have to be supported, and > > does have some security issues. > > Which ones? > It simply triggers a queue run filtering mail for a target server. Depending on the ability of your sendmail installation to determine spoofed connections, it *can* result in a DoS type of behavior. Based on the "MinQueueAge" and "Timeout.hoststatus" in sendmail.cf, it's possible to use a spoofing system to keep e-mail from getting to the right place in a timely fashion. Basically, you spoof to start the queue run and the server tries to send to the unconnected system. This generates a "touch" of the queue and a refresh of the host status directory (to failure). When the *real* place connects up to the Internet and calls to execute the ETRN, nothing gets sent because things had been tried sooner than the timeouts. The system hangs up off the Internet assuming that there is no mail. This could in theory go on long enough to result in a "non- deliverable" e-mail. -- Jeff Rife| "You keep using that word. I do not think it SPAM bait: | means what you think it means." [EMAIL PROTECTED] | [EMAIL PROTECTED] | -- Inigo Montoya, "The Princess Bride" ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On Thu, 12 Aug 2004, Kelson Vibber wrote: Sure, PGP and S/MIME are probably more elegant solutions. But if you think it's hard getting mail server admins to agree on and implement something like SPF, just try convincing every man, woman and child on the Internet to digitally sign every piece of outgoing mail! That's a problem of: a) how hard is it to sign a mail (try to sign a mail with PGP with Mozilla or Outlook for instance), b) how hard and cumbersum is it to gather a certificate (try to get a cert for S/Mime for instance). Both conditions above indicate that it is not easy, but it is not easy by intention; it gets even more painful when you try to set up such scenario for different mail addresses, aka "roles", e.g. when you participate in various projects, firms, or "morally bad" mailing lists. BTW: Many people think of PGP and S/Mime very personally, I mean, they believe that that you can be tracked down all the net by them. However, PGP signs are absolutely not human-personalized, only when you want to enter a partitucal web-of-trust. Also, PGP lacks the check currently, that you can ensure that the corresponding mail address is not faked as well. Bye, -- Steffen Kaiser ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On Thu, 12 Aug 2004, Jeff Rife wrote: And what do you think the command ETRN is for? It's an optional part of SMTP that doesn't have to be supported, and does have some security issues. Which ones? It simply triggers a queue run filtering mail for a target server. Bye. -- Steffen Kaiser ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 12 Aug 2004 at 12:33, Kelson Vibber wrote: > - Some of those criteria (such as spam filters) are hard to keep in sync > across multiple implementations. Spam isn't really a big deal in the bounce area. For us, once it hits analysis (SpamAssassin through MIMEDefang), we never send anything back to the sending server. DNSBL, forged HELO and virues get REJECTed (no bounce e-mail), but SPAM is silently dropped (for high scores) or sent on to the user. I just don't feel that any spammer deals with bad addresses well enough to make rejection worth while, nor is there a reason to tell somebody that they sent me spam, since the scores we use make it obvious that they already know. -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/UserFriendly/GeekCommunication.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 12 Aug 2004 at 10:14, Kelson Vibber wrote: > 1. Spammer targets the backup MX (us), assuming it's less protected. > 2. We queue, reject, or discard the message. > 3. Mail ends up at customer's primary mail server, which rejects *on > different criteria*. > 4. Customer's server issues an SMTP reject to our server. > > At this point, we technically *should* generate a bounce. The > address we sent it on to was valid, but the message could not be > delivered. I admit that I used shorthand to describe the process of making sure that the MX has the list of valid addresses. I should expand on that to say that if the MX accepts it, then it is deliverable. My solution to this would be if I had to use different rejection criteria from the MX that gets the mail first, I would not bounce the message, but instead just eat it. That's not the best thing to do, but my contract with the Internet is that once an MX that answers for me accepts the mail, the Internet doesn't need to be bothered any more. > On the other hand, if we > *did* have that information, we could have blocked the mail without > even queueing it up for the primary MX. > > Now if you run all your MXes yourself, you can make sure they all use the > same criteria and only reject mail at the border. But that's a bit more > difficult when one is in-house and the other belongs to your ISP We solve this merely by have a point of presence with enough ISPs (we have divisions or even just workers like me who use a different ISP) to allow us to run multiple MXs each with different connections to the backbone. > And then there's the scenario in which the forged message makes it > through to a valid address, someone reads it and fires off a > complaint to the person they think sent it... That's something that only user education will fix, so I'm not counting on seeing it happen anytime soon. :) -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/Dilbert/LostNetworkPassword.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 12 Aug 2004 at 10:20, Cor Bosman wrote: > > In any case, this is in reality no different from a client calling up > > and getting the mail from a server. Because the ISP is the only MX, it > > should know about all the deliverable addresses, simply to avoid > > dictionary e-mailings to these "offline" domains. > > In theory this sounds fine, in practise this is irrealistic. > Im assuming you dont run an ISP? The company I work for provides Internet services to clients. If you want to use your own mail server, you can, and e-mail goes directly to you through our link to the Internet (in other words, we provide connectivity only). If not, our server is MX and you give us the list of valid e-mail addresses and retrieve via POP (no IMAP because we don't want to be storing all their e-mail). You can have a server of your own to distribute e-mail, but you must get it off our server using "client" tools (like fetchmail or any MUA). The result is close to zero bogus e-mails hitting the postmaster account(s). > > I think I confuse ISP with "quality ISP". > > There is no need to be abusive to try and make your point. It makes your > point seem less valid. I'm not being abusive. More and more ISPs are heading towards things that reduce network abuse. One thing that does is having the full list of legal addresses on the answering MX. This is obviously more work for them in some ways, but the work it saves is worth the trouble to them and it has the nice side effect of reducing work for *other* Internet users. That's being "quality" or "responsible" in my book. > And what do you think the command ETRN is for? It's an optional part of SMTP that doesn't have to be supported, and does have some security issues. > One could give these > hosts a lower MX, but on the other hand, if they're almost never > online you'd have to wonder if thats a good thing. If they are almost never online, they are "clients", not servers, so they need to be treated as such. Harsh, I know, but treating them as clients in other ways (forcing them to use your server through the MSP port instead of the MTA port, for example) goes a long way to combatting network abuse. >This discussion started with implementing SPF, and > for an ISP implementing SPF has a lot of problems. Not unsolvable, > but it wont be pretty. On that, we agree. The biggest issue I see is the return-on-investment for making sure that everything is correct. In some cases, many just won't do things 100% because the "goal" (spam-reduction) doesn't seem to be something that SPF really will do. -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/OverTheHedge/HDTV.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Kelson Vibber wrote:
> Bad recipients are NOT the only problem!
I agree. Rejecting-bad-emails-at-the-gateway is a Good Idea (tm), but it doesn't
solve everything.
[EMAIL PROTECTED] 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
At 10:55 AM 8/12/2004, [EMAIL PROTECTED] wrote: Kelson Vibber wrote: > Let's try another ISP-as-MX scenario, this time where the company runs its > own mail server as primary MX, but uses the ISP's server as a secondary: Whoa... stop right there. If ISPs do this, there's a growing onus to maintain a "valid user" list, even without spam/virus filtering. The details are up to the ISP to determine - whether they hook up a scheduled feed from the customer (via, say, LDAP) or whether they ask the user to manage valid users via a web interface. No, you missed the point. Everyone's been so focused on bounces from mail sent to invalid users. Bad recipients are NOT the only problem! - Lots of different criteria can cause mail to bounce. - Some of those criteria (such as spam filters) are hard to keep in sync across multiple implementations. - There are fairly common circumstances under which mail will follow a chain of servers, and be rejected somewhere other than the first link. Here's another one: a simple forwarding address. 1. Message hits forwarder. 2. Forwarder redirects message to real mailbox at another service.* 3. Real mailbox is full, or rejects based on spam filtering. 4. Forwarder generates a bounce. * In this scenario, it doesn't matter whether the sender is rewritten, because we're assuming the real mailbox issues an SMTP reject when the forwarder connects. How do you prevent the bounce from being generated in this instance? And then there's the problem for which sender verification schemes (not just SPF, but the entire class) were actually designed, in which the forged message actually reaches a recipient: a. Phishing scams b. Trojan software (install this patch now!) c. Classic Joe-Jobs (i.e. targeted forgeries to tarnish your reputation) d. Complaints sent to the wrong people (such as your ISP's abuse desk) If a phisher has to use hotmail.com instead of paypal.com, fewer people are going to fall for the scam. If the "Launder your money now!" message is talking about your site but comes from yahoo.com, again it's going to be less effective. If the spammer has to use his own domain name, complaints will at least go to the right place instead of cluttering third-party abuse desks. Sure, PGP and S/MIME are probably more elegant solutions. But if you think it's hard getting mail server admins to agree on and implement something like SPF, just try convincing every man, woman and child on the Internet to digitally sign every piece of outgoing mail! Kelson Vibber SpeedGate Communications ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
I strongly agree with Matthew and David's statements about offering backup MX services. There is a lot of liability involved with offering that service, not to forget the enormous overhead. As an ISP we're always faced with this dilemma when offering mail routing services for clients that host their own MX/mail accounts, so in essence we still haven't escaped 100%, but certainly will never offer up any of our servers for backup MX purposes, just too risky. - Chris -- Chris Gauch Systems Administrator Digicon Communications, Inc. [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:mimedefang- > [EMAIL PROTECTED] On Behalf Of David F. Skoll > Sent: Thursday, August 12, 2004 2:38 PM > To: [EMAIL PROTECTED] > Subject: RE: [Mimedefang] Deadline for SPF records *long w/morbid > horoscope* > > On Thu, 12 Aug 2004 [EMAIL PROTECTED] wrote: > > > But accept-everything-and-send-manual-undeliverable-reports-later is > > becoming less and less acceptable of a strategy. > > I concur. I suspect ISPs will find it less and less attractive to > offer backup MX services, and will either get out of that business > or start charging (a lot) more. > > Regards, > > David. > ___ > Visit http://www.mimedefang.org and http://www.canit.ca > MIMEDefang mailing list > [EMAIL PROTECTED] > http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
> >> Again, this completely solves the issue of forged return address > >> bounce e-mails. > > > > Actually, no it doesn't. > > > > Let's try another ISP-as-MX scenario, this time where the company runs its > > own mail server as primary MX, but uses the ISP's server as a secondary: > > Whoa... stop right there. If ISPs do this, there's a growing onus to maintain a > "valid user" list, even without spam/virus filtering. The details are up to the ISP > to determine - whether they hook up a scheduled feed from the customer (via, say, > LDAP) or whether they ask the user to manage valid users via a web interface. It's not a question of ISPs doing it, it's a fact that ISPs have been doing it for many many years. From way before spam became a problem. Changing it is not going to be pretty. Try and tell 100.000 customers that they have to maintain a valid userlist with you. It's possible (for certain interpretations of possible), but very very costly and timeconsuming. Ofcourse it's easy when you run your little homesystem for you and your wife. Sure it's easy when you have 15 employees that you can force a change upon. It is not easy, not by a long shot, to change the behavior of many many customers. It is not a question of 'changing a door'. It's a question of changing 10.000 doors, some of which you didnt even know existed, some of which baffle even you, and you run the damn system, some of which have had keys made in gold with jewels laid in, some of which have 5000 copy keys unbeknownst to you, and you need to tell the user of that door to please give everyone a new key and they dont even know who uses it. Some of these doors are used by lawfirms just aching to sue you. Changing anything, even something seemingly benign, often has large implications. Now dont think that that means ISPs dont want to fix things. ISPs have been fixing things and are fixing things. We are as we speak implementing a very large mimedefang system (50+ servers) to move more and more checks to the front door so we can reject there. But I am realistic enough to know it's never going to be 100%. There will always be noise on the line. > But accept-everything-and-send-manual-undeliverable-reports-later is becoming less > and less acceptable of a strategy. Just to clarify. The person you are replying on said that it might very well be that you are accepting for a valid recipient as a secondary MX, but the primary can still reject you for totally different reasons. The secondary would then have to bounce. Thats part of the noise.. How far are we from banning each and every bounce? :) "Dear ISP, I got a bounce that my email cant be delivered, please stop! I dont want to know!" :) I give it 1 year max. Regards, Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On Thu, 12 Aug 2004 [EMAIL PROTECTED] wrote: > But accept-everything-and-send-manual-undeliverable-reports-later is > becoming less and less acceptable of a strategy. I concur. I suspect ISPs will find it less and less attractive to offer backup MX services, and will either get out of that business or start charging (a lot) more. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
[EMAIL PROTECTED] wrote on 08/12/2004 01:55:55 PM: > But accept-everything-and-send-manual-undeliverable-reports-later is > becoming less and less acceptable of a strategy. Hear! Hear!! I looked at a number of spam filters that did this before I came across MIMEDefang (and CanIT Pro which we use). One of the strongest points in my mind is the fact that it rejects the message during the SMTP conversation. We purchased CaniIT Pro for the ability to handle different filtering streams. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Kelson Vibber wrote:
> At 06:27 PM 8/11/2004, Jeff Rife wrote:
>> it is the responsibility of the MX machine to know what is and is
>> not deliverable.
>>
>> Again, this completely solves the issue of forged return address
>> bounce e-mails.
>
> Actually, no it doesn't.
>
> Let's try another ISP-as-MX scenario, this time where the company runs its
> own mail server as primary MX, but uses the ISP's server as a secondary:
Whoa... stop right there. If ISPs do this, there's a growing onus to maintain a
"valid user" list, even without spam/virus filtering. The details are up to the ISP
to determine - whether they hook up a scheduled feed from the customer (via, say,
LDAP) or whether they ask the user to manage valid users via a web interface.
But accept-everything-and-send-manual-undeliverable-reports-later is becoming less and
less acceptable of a strategy.
[EMAIL PROTECTED] 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
At 06:27 PM 8/11/2004, Jeff Rife wrote: it is the responsibility of the MX machine to know what is and is not deliverable. Again, this completely solves the issue of forged return address bounce e-mails. Actually, no it doesn't. Let's try another ISP-as-MX scenario, this time where the company runs its own mail server as primary MX, but uses the ISP's server as a secondary: 1. Spammer targets the backup MX (us), assuming it's less protected. 2. We queue, reject, or discard the message. 3. Mail ends up at customer's primary mail server, which rejects *on different criteria*. 4. Customer's server issues an SMTP reject to our server. At this point, we technically *should* generate a bounce. The address we sent it on to was valid, but the message could not be delivered. We have no way of knowing, short of something SPF-like provided by the apparent sender's domain, whether the return address is valid, invalid, or valid-but-forged. On the other hand, if we *did* have that information, we could have blocked the mail without even queueing it up for the primary MX. Now if you run all your MXes yourself, you can make sure they all use the same criteria and only reject mail at the border. But that's a bit more difficult when one is in-house and the other belongs to your ISP, who may not even be running the same mail server software as you, never mind the same filtering software. And then there's the scenario in which the forged message makes it through to a valid address, someone reads it and fires off a complaint to the person they think sent it... Kelson Vibber SpeedGate Communications ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
[EMAIL PROTECTED] wrote on 08/12/2004 04:20:31 AM: > And what do you think the command ETRN is for? One could give these hosts > a lower MX, but on the other hand, if they're almost never online you'd have > to wonder if thats a good thing. ETRN requires the queueing MX to be able to resolve the requsting host. ETRN only tells the server that it should process and deliver any mail mail destined to the requesting server via a new connection. It does not simply reverse the direction of mail flow over the exisiting connection. TURN used to do that, but it was very insecure having no validation for who was asking for the email. You still need a lower preference MX, if only on an internal DNS zone, to deliver the mail after ETRN. > Dont forget, the internet is older than the spam problem. Im not saying these > kinds of setups cant be changed, im saying they're not trivial to change. > This discussion started with implementing SPF, and for an ISP implementing > SPF has a lot of problems. Not unsolvable, but it wont be pretty. Yep, and it's a pain in the a$$ to replace the door on your house, but if it keeps the unwated (cold air,burglars) out, it might be worth the cost/effort. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
> > This is not true. Im not sure how many 'most' ISPs you are talking > > about, but I know quite a few ISPs that accept all email for a > > domain and forward to a customer. This is most prevalent in > > dialup/isdn situations where you basically 'store and forward' all > > email for customers that are mostly offline. When they come online > > that triggers a queuerun towards the customer. > > In many cases, this is handled not by server-to-server, but by a client > contacting the ISP server and retrieving the e-mail and then sorting it > out in whatever way. In many other cases this is handled by MTA<>MTA traffic. > In any case, this is in reality no different from a client calling up > and getting the mail from a server. Because the ISP is the only MX, it > should know about all the deliverable addresses, simply to avoid > dictionary e-mailings to these "offline" domains. In theory this sounds fine, in practise this is irrealistic. Im assuming you dont run an ISP? It would mean you would have to create automated emailalias syncing with every customer with this type of setup, no matter what their software is. > I think I confuse ISP with "quality ISP". There is no need to be abusive to try and make your point. It makes your point seem less valid. > > And again, you are wrong :) > > Not for "real" domains. If the ISP is the *only* MX and you retrieve > your e-mail as if you are a client (not an MTA), then it is the > responsibility of the MX machine to know what is and is not > deliverable. And that's where the heart of this confusion is. We do indeed have tens of thousands of customers that pick up their email with client software. POP, IMAP, even webmail. But we have quite a few customers where this is done with MTA traffic. Customer comes online and the authentication itself triggers a push of the queue. I know several ISPs in our area alone that do this. And what do you think the command ETRN is for? One could give these hosts a lower MX, but on the other hand, if they're almost never online you'd have to wonder if thats a good thing. Dont forget, the internet is older than the spam problem. Im not saying these kinds of setups cant be changed, im saying they're not trivial to change. This discussion started with implementing SPF, and for an ISP implementing SPF has a lot of problems. Not unsolvable, but it wont be pretty. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 11 Aug 2004 at 10:38, Cor Bosman wrote: > > The companies that offer #2 also offer ways for you to retrieve the e- > > mail with your MUA software, so they don't *want* to deal with passing > > it on to an MTA. > > This is not true. Im not sure how many 'most' ISPs you are talking > about, but I know quite a few ISPs that accept all email for a > domain and forward to a customer. This is most prevalent in > dialup/isdn situations where you basically 'store and forward' all > email for customers that are mostly offline. When they come online > that triggers a queuerun towards the customer. In many cases, this is handled not by server-to-server, but by a client contacting the ISP server and retrieving the e-mail and then sorting it out in whatever way. In any case, this is in reality no different from a client calling up and getting the mail from a server. Because the ISP is the only MX, it should know about all the deliverable addresses, simply to avoid dictionary e-mailings to these "offline" domains. > You perhaps confuse ISP with US ISP? I think I confuse ISP with "quality ISP". > > So, again, I think it's pretty odd for an ISP to be *the* MX for your > > domain but then just pass it along to your server. > > And again, you are wrong :) Not for "real" domains. If the ISP is the *only* MX and you retrieve your e-mail as if you are a client (not an MTA), then it is the responsibility of the MX machine to know what is and is not deliverable. Again, this completely solves the issue of forged return address bounce e-mails. -- Jeff Rife| "In those days Mars was a dreary uninhabitable SPAM bait: | wasteland much like Utah, but unlike Utah, Mars [EMAIL PROTECTED] | was eventually made livable." [EMAIL PROTECTED] | -- Professor Farnsworth, "Futurama" ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
> > >>If your ISP allows you to have mail servers behind theirs and they are > > >>the "front line MX" and forward everything to you, then your ISP is > > >>really odd. > > > > > > > > > This is not odd at all. > > > Now, for *real* ISPs (like, say Comcast, who provide both connectivity > *and* service), most also will not be the MX for *your* domain, unless > you set up the domain with them and tell them what e-mail addresses > should be accepted for delivery. Even so, most still won't then pass > that on to your server...they assume you are an individual or a group > of individuals who don't know how to set up a server...that's why they > offer the service. > > Basically, there are 2 ways to deal with domain e-mail: > 1. receive it yourself on a server you control > 2. contract out the receiving in some way > > The companies that offer #2 also offer ways for you to retrieve the e- > mail with your MUA software, so they don't *want* to deal with passing > it on to an MTA. This is not true. Im not sure how many 'most' ISPs you are talking about, but I know quite a few ISPs that accept all email for a domain and forward to a customer. This is most prevalent in dialup/isdn situations where you basically 'store and forward' all email for customers that are mostly offline. When they come online that triggers a queuerun towards the customer. You dont want that customer to have lower MX records because that would be unfair to senders who most of the time try in vain. You perhaps confuse ISP with US ISP? > So, again, I think it's pretty odd for an ISP to be *the* MX for your > domain but then just pass it along to your server. And again, you are wrong :) Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 10 Aug 2004 at 14:29, Ben Kamen wrote: > >>If your ISP allows you to have mail servers behind theirs and they are > >>the "front line MX" and forward everything to you, then your ISP is > >>really odd. > > > > > > This is not odd at all. > > I concur. > > This is not odd at all and is actually the goal of people like MSN.com. To their > mail server, your mail server could be an MTA, MSA or MUA. They don't care... > they'll take anything. I don't think this is true about MSN.com. Yes, you could have your MSN account forward to your "real" account, or you could use something like fetchmail to retrieve your MSN mail and drop it into your local sendmail queue and then do whatever you want. But, the MSN.com mailserver doesn't accept all mail for "mydomain.com" and then pass it on to a lower-numbered MX for "mydomain.com". This is because MSN isn't a "real" ISP...they only provide service to individuals, and *only* provide one domain. Now, for *real* ISPs (like, say Comcast, who provide both connectivity *and* service), most also will not be the MX for *your* domain, unless you set up the domain with them and tell them what e-mail addresses should be accepted for delivery. Even so, most still won't then pass that on to your server...they assume you are an individual or a group of individuals who don't know how to set up a server...that's why they offer the service. Basically, there are 2 ways to deal with domain e-mail: 1. receive it yourself on a server you control 2. contract out the receiving in some way The companies that offer #2 also offer ways for you to retrieve the e- mail with your MUA software, so they don't *want* to deal with passing it on to an MTA. > Now for business accounts, that's another story. And, most ISP accounts that involve domains that aren't the ISPs domain fall under this heading. So, again, I think it's pretty odd for an ISP to be *the* MX for your domain but then just pass it along to your server. -- Jeff Rife| "I once did a news report on the dangers of SPAM bait: | plastic surgery, and do you know what the [EMAIL PROTECTED] | statistics say?" [EMAIL PROTECTED] | "Yes...that 9 out of 10 men prefer women | with big boobs." | "And the 10th guy preferred the 9 other men." | -- "Just Shoot Me" ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Cor Bosman wrote: How about "scaling"? I'm pretty sure my ISP will run (screaming, no doubt), from a scenario in which they rely on their customers to keep their list of valid addresses current. If your ISP allows you to have mail servers behind theirs and they are the "front line MX" and forward everything to you, then your ISP is really odd. This is not odd at all. I concur. This is not odd at all and is actually the goal of people like MSN.com. To their mail server, your mail server could be an MTA, MSA or MUA. They don't care... they'll take anything. Users cannot email WITHOUT relaying through their servers. Now for business accounts, that's another story. -Ben ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
> > How about "scaling"? I'm pretty sure my ISP will run (screaming, no > > doubt), from a scenario in which they rely on their customers to keep > > their list of valid addresses current. > > If your ISP allows you to have mail servers behind theirs and they are > the "front line MX" and forward everything to you, then your ISP is > really odd. This is not odd at all. Cor ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 10 Aug 2004 at 9:04, Graham Dunn wrote: > > There is no reason a backup MX server can't know if an address is valid > > or not. > > How about "scaling"? I'm pretty sure my ISP will run (screaming, no > doubt), from a scenario in which they rely on their customers to keep > their list of valid addresses current. If your ISP allows you to have mail servers behind theirs and they are the "front line MX" and forward everything to you, then your ISP is really odd. If, on the other hand, you just use your ISP as backup MX, *and* they don't run MIMEDefang, etc., then you lose a lot of the benefits of running MIMEDefang. The solution my small (less than 300 employees) company chose was to put another Linux server *that we control* somewhere else. We can do this because we have a couple of different ISPs for our different physical locations. > How about "MS Exchange"? :] How about it? There are lots of ways you can automatically generate all valid e-mail addresses from an Exchange server, and get those to a Linux box in a way that MIMEDefang can use to verify. We, instead, chose to educate our president and officers about the actual costs of Exchange, and it left the building quite unceremoniously. -- Jeff Rife| SPAM bait: | http://www.nabs.net/Cartoons/AngryTVGod.gif [EMAIL PROTECTED] | [EMAIL PROTECTED] | ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 10 Aug 2004 at 9:00, Joseph Brennan wrote: > --On Monday, August 9, 2004 11:17 PM -0400 Jeff Rife <[EMAIL PROTECTED]> > wrote: > > >> At the core, this solution ignores the concept and purpose of a backup MX > >> which is a reality and necessity for many companies where email is > >> critical. > > > I dispute this statement. That's as may be, but check your quoting next time, because I didn't write it. -- Jeff Rife| "Wheel of morality, SPAM bait: | Turn, turn, turn. [EMAIL PROTECTED] | Tell us the lesson [EMAIL PROTECTED] | That we should learn" | -- Yakko, "Animaniacs" ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On Mon, Aug 09, 2004 at 11:17:41PM -0400, Jeff Rife wrote: > On 9 Aug 2004 at 21:03, Kevin A. McGrail wrote: > > > > If the receiving MX servers always knew all valid recipient addresses > > > *at (E)SMTP connection time*, then there would be no bounces...only > > > rejections. > > > > > > This solves the problem without introducing anything new to (E)SMTP. > > > > At the core, this solution ignores the concept and purpose of a backup MX > > which is a reality and necessity for many companies where email is critical. > > There is no reason a backup MX server can't know if an address is valid > or not. How about "scaling"? I'm pretty sure my ISP will run (screaming, no doubt), from a scenario in which they rely on their customers to keep their list of valid addresses current. How about "MS Exchange"? :] Graham ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
--On Monday, August 9, 2004 11:17 PM -0400 Jeff Rife <[EMAIL PROTECTED]> wrote: At the core, this solution ignores the concept and purpose of a backup MX which is a reality and necessity for many companies where email is critical. I dispute this statement. If the MX host is configured differently it could cause more problems that just letting remote hosts re-try to the regular mail server. Joseph Brennan Academic Technologies Group, Academic Information Systems (AcIS) Columbia University in the City of New York ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Jeff Rife said: headers become the norm. > > If the receiving MX servers always knew all valid recipient addresses > *at (E)SMTP connection time*, then there would be no bounces...only > rejections. > > This solves the problem without introducing anything new to (E)SMTP. Even though my gateway machines don't have the address books of the internal machines. I don't get very many bounce backs. As most mail get's rejected as spam, before it bounces back though. I tried to get read the ldap address book entries from my internal exchange server (5.5) but I could never get it to work. I couldn't justify the effort as I'm don't really see it as a big deal at this point. I'm sure i should, but I can't justify the effort for the return. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 9 Aug 2004 at 21:03, Kevin A. McGrail wrote: > > If the receiving MX servers always knew all valid recipient addresses > > *at (E)SMTP connection time*, then there would be no bounces...only > > rejections. > > > > This solves the problem without introducing anything new to (E)SMTP. > > At the core, this solution ignores the concept and purpose of a backup MX > which is a reality and necessity for many companies where email is critical. There is no reason a backup MX server can't know if an address is valid or not. -- Jeff Rife| "These are not scraps. These are historic SPAM bait: | remains of a once-great society of hair." [EMAIL PROTECTED] | [EMAIL PROTECTED] | -- George Costanza ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
> If the receiving MX servers always knew all valid recipient addresses > *at (E)SMTP connection time*, then there would be no bounces...only > rejections. > > This solves the problem without introducing anything new to (E)SMTP. At the core, this solution ignores the concept and purpose of a backup MX which is a reality and necessity for many companies where email is critical. I also believe moving towards publishing valid email lists (even privately) as in the do-not-email list will leads back to all methods being used to gain access to those lists. Having seen companies as large as AOL and Verio lose track of internal lists of email address that then wound their way to Spammers, a better solution relies on information that isn't damaging when public (i.e. SPF ns TXT records). Valid recipient bouncing is a short-term solution but like greylisting, eventually ratware and tactics will catch up. KAM ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
On 9 Aug 2004 at 20:21, Kevin A. McGrail wrote: > I thought about the statement below a lot because it seemed correct at first > that pushing valid emails to all the gateways would solve the issue. > However, the more I thought about it, invalid bounces are a big problems and > SPF is a reasonable solution to start cutting down on them. Large batches > of outbound false emails that don't match SPF or get repeated bounces should > trigger a shutdown of a clients outbound mailing ability especially as > worms/virii that forge headers become the norm. If the receiving MX servers always knew all valid recipient addresses *at (E)SMTP connection time*, then there would be no bounces...only rejections. This solves the problem without introducing anything new to (E)SMTP. -- Jeff Rife| "Space. It seems to go on and on forever. But SPAM bait: | then you get to the end and a gorilla starts [EMAIL PROTECTED] | throwing barrels at you." [EMAIL PROTECTED] | -- Philip J. Fry, "Futurama" ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Deadline for SPF records *long w/morbid horoscope*
Re: SPF Solving Invalid Bounces I thought about the statement below a lot because it seemed correct at first that pushing valid emails to all the gateways would solve the issue. However, the more I thought about it, invalid bounces are a big problems and SPF is a reasonable solution to start cutting down on them. Large batches of outbound false emails that don't match SPF or get repeated bounces should trigger a shutdown of a clients outbound mailing ability especially as worms/virii that forge headers become the norm. Further, there was a time, not to long ago, when accepting all emails was the "correct" thing to do for the security conscience and I think that time will come back especially if things such as silent discards become more accepted. In other words, having a valid list of users is not always feasible, secure, or allow for queuing during outages/netsplits. I also predict that the minute systems that turn away bad emails at the gateway become ubiquitous, attacks to harvest and obtain those lists will become common place again and dictionary attacks will become less common. SPF is very good in one respect that it is only based on text records. There is no hidden tactics and no harvesting issues that I can see. If implemented in a scoring manner (which is the only method I promote), it has a lot of benefits with very little downfalls. OK, one downfall... For my two cents, the biggest problem which I have witnessed on a very small scale and which has the potential to de-rail virtually any of this email "systems" is a Distributed AND Coordinated System that literally sends a miniscule # of spams (say ONE spam message per day per infected system). I call them DACs and let's say they are sent from a legit users email box, through the correct server, with SPF records, with a valid escrow account (if that system ever wins), no multiple recipients, with a valid MTA, all to valid accounts, etc. Now multiply that by say 45 million infected boxes sending 1 email per day instead of 1 box sending 45 million emails per day. Now consider doing the same thing to harvest good email addresses by looking for one bad or good email per day. Now include address books which are compromised on the same systems and search mail (slowly) on the system and detect all outgoing email addresses for the last 6 months. Now add the ability to remotely control the zombie system so it sends outbound and inbound data (perhaps over port 80 or something 99.9% of the people won't catch. And remember, we only trickle a little out at a time. Maybe 80-bytes a day. Now remember that SPAM (unlike viruses, we hope) = Money = Business = People for Hire. In short, if a virus/worm can get control, moderate the actions, spice up the differences they have, etc. they have a much greater potential to come under the radar for a lot longer. The last major worm/virii brought down an uber-distributed system like google. Imagine if they had actually planned to do that and did it only after reaching a much larger critical mass. Oh wait, I forgot SP2 will save us :-P Regards, KAM > I agree that invalid bounces from forged addresses aren't really a blip > on the scale of email problems. Also they can easily be solved using > existing technology - just have every organization push their "valid > user" list to the mail servers on their network boundary. Then the mail > will be rejected at RCPT TO time, with no undeliverable message > generated. (The ratware and spamware won't generate an undeliverable > message when faced with a 550 No such user.) ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
