Subject: eml message - msg#00296

Previous Message by Date: click to view message preview

RE: Mail spoofing by hosted users?

Hi, Thank you, I appreciate your detailed response. Well, now that I can see different ways of doing this. Let me test it on my test setup, after I get a feeling how good each approach is. I will roll it on production. ________________________________________________________________________ ___ Thanks and Regards, Nasarullah Sheikh SCSA, SCNA, SCFE, SCCI 3.x -----Original Message----- From: Kristin Hubner [mailto:kristin.hubner-xsfywfwIY+M@xxxxxxxxxxxxxxxx] Sent: Thursday, August 24, 2006 3:08 PM To: Sheikh, Nasarullah Cc: Dan Newman; iMS Mailing List Subject: Re: [Info-iMS] Mail spoofing by hosted users? On Aug 23, 2006, at 7:54 PM, Sheikh, Nasarullah wrote: > > Hi, > I absolutely agree with you on the From: reliability. Infact > authrewrite 1 - introducing a Sender: is fine for me aswell as my > users. > Here I would like to add that Outlook - shows the Sender: information > in > the short headers too ( unlike webmail or other clients ). So my users > (mostly Outlook clients) can see the actual "Sender:" even in the short > headers in the e-mail ...when Sender: is present in the headers. > The e-mail looks like > > -----Original Message----- > From: actual_emailaADD-9IKiO1iGCm/QT0dZR+AlfA@xxxxxxxxxxxxxxxx [mailto: actual_emailaADD-9IKiO1iGCm/QT0dZR+AlfA@xxxxxxxxxxxxxxxx] > On Behalf Of YAHOO_CEO > Sent: Thursday, August 24, 2006 2:59 AM > To: someuser@domain > Subject: sdf > > Further, I know for mails coming from internet (non-internal-hosted > Domains) the From: can be forged, and there is no auth for that kind of > a mail. My users are also aware of such spam, but that is from > internet. > > My problem is actually on a different point. > > I have restricted the e-mails to internet for some internal users, > based > on the mappings rule > > ORIG_SEND_ACCESS > > tcp_*|*_int@*|tcp_local|* $NINTERNET$ EMAIL$ NOT$ PERMITTED > > So all those user with a _int as suffix on their e-mail cannot send > mails to internet as a policy. > > In this scenario...when such user forges the e-mail in Outlook to > remove > _int he can successfully send mails to internet !! > Ah, now that sounds like you have a reasonable restriction you want to impose. (And it's the envelope From: you're concerned about -- for your purposes concerned about it indirectly due to its relevance for access blocking -- rather than the header From:.) So to do that with FROM_ACCESS as you were attempting, I suggest something more like: FROM_ACCESS ! If the envelope From: and authenticated sender already match, accept *|SMTP*|*|tcp_auth|*|$3* $Y ! If they match modulo use of a subaddress, accept *|SMTP*|*|tcp_auth|*+*@*|$3*@$5* $Y ! Otherwise, check if the authenticated user address contains _int and if so ! force envelope From: to correspond *|SMTP*|*|tcp_auth|*|*_int@* $Y$J$4_int@$5 ! Let other users send using alternate envelope From:'s. * $Y Then your ORIG_SEND_ACCESS check should do the _int user attempting to send to the Internet check. Why that sort of approach wasn't working for you -- well, for that I'd like to see some debugging. However, I think I would prefer to use one of the following approaches instead. (1) Use a FROM_ACCESS mapping table to enforce that the _int users MUST use that _int address as their envelope From:, regardless of what To: address they might (later) attempt. That way, any attempts that they might make to forge their envelope From: address get rejected at the MAIL FROM: stage, rather than subsequently at the RCPT TO: stage (and rather than having the more complex, perhaps more subject to breaking later, configuration where FROM_ACCESS first modifies the envelope From: and ORIG_SEND_ACCESS later checks it). E.g., FROM_ACCESS *|SMTP*|MAIL|tcp_auth|*+*@*|*_int@* $CINT|$2@$4|$5_int@$6 *|SMTP*|MAIL|tcp_auth|*|*_int@* $CINT|$2|$3_int@$4 INT|*|$0* $Y INT|* $NFrom:$ address$ invalid Note that in the above approaches I haven't addressed the issue of submissions to the SMTP SUBMIT port (submissions on the tcp_submit channel). You'll probably want to handle that case too, via additional entries. (2) Set a mailSMTPSubmitChannel attribute on each _int user that points to some special channel, say tcp_auth_int. That way, when they authenticate their messages will get "switched" to tcp_auth_init rather than the usual saslswitchchannel-based switch to tcp_auth. Then use an ORIG_SEND_ACCESS mapping table that blocks tcp_auth_int messages from going out tcp_local, e.g., ORIG_SEND_ACCESS tcp_auth_int|*|tcp_local|* $NINTERNET$ EMAIL$ NOT$ PERMITTED Approach (2) is more provisioning work -- however, depending upon what you really want to do with these "restricted" users, it may be work that is well worthwhile, as having the messages from these "restricted" users come in their own special channel allows you to make other distinctions about their messages more easily. Regards, Kristin > So I am trying to enforce the substitution of Sender: on the From: by > > -------- > FROM_ACCESS > > *|SMTP|*|tcp_auth|*| $Y > *|SMTP|*|tcp_auth|*|* $Y$J$3 > > ----------------------------------------------------------------------- > > > FOR HOSTED INTERNAL USERS ONLY ... > > After doing this the ORIG_SEND_ACCESS mapping rule above should stop > such users to send mail out to internet...that is my idea... > _______________________________________________________________________ > _ > ___ > > Thanks and Regards, > > Nasarullah Sheikh > > SCSA, SCNA, SCFE, SCCI 3.x > > -----Original Message----- > From: Kristin Hubner [mailto:kristin.hubner-xsfywfwIY+M@xxxxxxxxxxxxxxxx] > Sent: Thursday, August 24, 2006 1:10 AM > To: Sheikh, Nasarullah > Cc: Dan Newman; iMS Mailing List > Subject: Re: [Info-iMS] Mail spoofing by hosted users? > > > On Aug 23, 2006, at 1:06 AM, Sheikh, Nasarullah wrote: > >> Hi Gurus, >> Now that I am getting the Sender in the header...I want > to >> replace the actual From: with the Sender: > > That is a REALLY BAD idea, contrary to the standards, and makes your > users > MORE VULNERABLE (because more naive) to forged messages from malicious > remote senders. > > You cannot change the entire rest of the Internet behavior (where the > standards > say that From: is NOT a header line that necessarily shows the "real" > sender > of a message, and that Sender: is instead the "authenticated" address). > From: in contrast is _intended_ to allow for uses such as a secretary > sending on > behalf of a manager, or for users who function in multiple "roles" > (personal, > help desk, whatever) to send messages with different "From:'s" > depending upon > the "role" in which they are acting. Plus, besides the various > legitimate > uses (such as just described above) for alternate "From:" addresses, > there are > also the ever-present spam or phishing messages that use forged "From:" > > addresses. > > So instead you should encourage your users to become more sophisticated > > and wary: > to use, and look for in the messages they receive, the Sender: header > line instead. > That way, you are doing the "correct" thing, and your users are gently > educated > into proper e-mail usage, rather than promoting the delusion that the > "From:" has > any inherent reliability. > > Regards, > > Kristin > >> As per Admin guide of my working version (iMS 5.2 hf 2.08) >> http://docs.sun.com/source/816-6009-10/filter.htm >> > ======================================================================= >> = >> ====== >> Besides determining whether to allow a message to be submitted based > on >> the originator, FROM_ACCESS can also be used to alter the envelope >> From: >> address via the $J flag, or to modify the effect of the authrewrite >> channel keyword (adding a Sender: header address on an accepted >> message) >> via the $K flag. For instance, this mapping table can be used to cause >> the original envelope From: address to simply be replaced by the >> authenticated address: >> > ----------------------------------------------------------------------- >> - >> -------- >> >> FROM_ACCESS >> >> *|SMTP|*|tcp_local|*| $Y >> *|SMTP|*|tcp_local|*|* $Y$J$3 >> >> >> > ----------------------------------------------------------------------- >> - >> -------- >> > ======================================================================= >> = >> ====== >> >> I tried the above....even changed the tcp_local to tcp_auth !! >> But I could not get the desired result...??? >> >> Am I doing something wrong???? >> >> >> > _______________________________________________________________________ >> _ >> ___ >> >> Thanks and Regards, >> >> Nasarullah Sheikh >> >> SCSA, SCNA, SCFE, SCCI 3.x >> >> -----Original Message----- >> From: Sheikh, Nasarullah >> Sent: Wednesday, August 23, 2006 2:04 PM >> To: 'Kristin Hubner'; 'Dan Newman' >> Cc: iMS Mailing List >> Subject: RE: [Info-iMS] Mail spoofing by hosted users? >> Importance: High >> >> Hi Gurus, >> Thanks I added the "authrewrite 1" to tcp_auth....it worked. Now > >> I >> am getting Sender: in the header. >> Sender: header however contains the actual e-mail address of the >> Sender >> and not uid@xxxxxxxxxxxxxx is even better. >> I had opened a Case ID: 10900701 for this. But, the response as always >> was slow and irrelevant. >> Thanks Anyway! >> >> > _______________________________________________________________________ >> _ >> ___ >> >> Thanks and Regards, >> >> Nasarullah Sheikh >> >> SCSA, SCNA, SCFE, SCCI 3.x >> >> >> -----Original Message----- >> From: Kristin Hubner [mailto:kristin.hubner-xsfywfwIY+M@xxxxxxxxxxxxxxxx] >> Sent: Wednesday, August 23, 2006 2:15 AM >> To: Sheikh, Nasarullah >> Cc: iMS Mailing List >> Subject: Re: [Info-iMS] Mail spoofing by hosted users? >> >> >> On Aug 21, 2006, at 11:51 PM, Sheikh, Nasarullah wrote: >> >>> Hi Dan, >>> I have added "authrewrite 1" in the tcp_local channel on the >>> mta >> >> If you have a normal sort of configuration, a "saslswitchchannel" >> effect >> will be "switching" submissions that authenticated to tcp_auth. So > you >> would need "authrewrite 1" on tcp_auth (and potentially tcp_submit, if >> you have users submitting to the SMTP SUBMIT port) rather than on >> tcp_local. >> >> Do note also that this needs to be set on the host where the message > is >> initially submitted -- it has no effect on relayed messages (messages >> submitted initially to some other MTA, and now being relayed from >> another MTA). >> >> Regards, >> >> Kristin >> >>> aswell as my backend message store. But, the "Sender:" header does > not >>> get inserted in the e-mail??? >>> >>> >>> >> > _______________________________________________________________________ >>> _ >>> ___ >>> >>> Thanks and Regards, >>> >>> Nasarullah Sheikh >>> >>> >>> >>> -----Original Message----- >>> From: Dan Newman [mailto:dan.newman-xsfywfwIY+M@xxxxxxxxxxxxxxxx] >>> Sent: Tuesday, August 22, 2006 10:25 AM >>> To: Sheikh, Nasarullah >>> Cc: Info-iMS-QMRIvgJGioDQT0dZR+AlfA@xxxxxxxxxxxxxxxx >>> Subject: Re: [Info-iMS] Mail spoofing by hosted users? >>> >>> Sheikh, Nasarullah wrote: >>>> Hi Gurus, >>>> We are running iMS5.2 hf 2.08 messaging setup. >>>> Lately I found out that our internal mail users (hosted) can spoof >>> their >>>> From address using Outlook client. E.g >>>> A user with userid userA-y3PpSDMNKENBDgjK7y7TUQ@xxxxxxxxxxxxxxxx and >>>> e-mail euserA-y3PpSDMNKENBDgjK7y7TUQ@xxxxxxxxxxxxxxxx >>> can >>>> change his From address to anything other than his actual mail >>>> address...like ceo-y3PpSDMNKENBDgjK7y7TUQ@xxxxxxxxxxxxxxxx / >>>> ceo-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx etc >>> >>> Internet e-mail is designed to allow this: users are expected and >>> allowed >>> to set whatever From: address they want. MTAs should then add a >>> Sender: >>> header line when the address in the From: header line differs from > the >>> known, authenticated address of the message originator. >>> >>> As an aside, for some mysterious reason users *trust* computers and >> are >>> taken aback when they learn this about the From: header line. The >> same >>> people usually are better educated about paper, postal mail and >>> recognize >>> that they can write a letter claiming to be from anyone they choose, >>> and >>> then put that in an envelope and mail it. I suspect that some of > this >>> familiarity stems from them understanding the mechanics of paper mail >>> while >>> the computer and its workings are far less familiar to them. As > such, >>> some >>> user education is often called for in this situation. >>> >>>> What is the way to stop such spoofing? >>>> All our hosted mail users are forced to use SMTP auth. >>> >>> Herein lies the standards based answer: add a Sender: header line. >>> Have >>> that header line contain the address of the authenticated sender >> (i.e., >>> the information you learned from the SMTP AUTH step). Add that > header >>> line when you initially accept the message from the originator. See >>> the >>> description of the "authrewrite" channel keyword for further details, >>> >>> http://docs.sun.com/source/816-6009-10/channel.htm#35400 >>> >>> And, thank you for always requiring SMTP authentication! >>> >>> Regards, >>> Dan >>> >> >> > >

Next Message by Date: click to view message preview

Broken URLs in Messenger Express

Hello all, We recently completed a successful upgrade from 5.2 to 6.2. And all is good. However now even after patching Messenger Express from the -51 patch we have a situation were linked urls in the body text of the message will have one character missing. The missing characters are different in various urls but will repeat the position for a given url. Does this ring any bells? Thanks, Mark

Previous Message by Thread: click to view message preview

Message queue injection from one MTA to another

All, Hopefully this is a simple answer, but we're looking at rebuilding an MTA and rather than waiting 7 days for the message queues to drain, we would like to inject that particular server's queue into another MTA we've got. What steps might we go about to achieve this? I remember someone mentioning something about it at one point, but I can't seem to find it in my archives or in any online docs. Thanks, Mike McMurray

Next Message by Thread: click to view message preview

Broken URLs in Messenger Express

Hello all, We recently completed a successful upgrade from 5.2 to 6.2. And all is good. However now even after patching Messenger Express from the -51 patch we have a situation were linked urls in the body text of the message will have one character missing. The missing characters are different in various urls but will repeat the position for a given url. Does this ring any bells? Thanks, Mark