Archive-Date: Mon, 4 Feb 2002 05:13:23 -0800 Message-ID: <496754D21EDBD311963800C04F012BEB48C5C9@srv-cho.CHASLEVY.com> From: "Ferguson, Linwood" Reply-To: MX-List@MadGoat.com To: "'MX-List@MadGoat.com'" Subject: RBL Lists Date: Mon, 4 Feb 2002 07:12:12 -0600 MIME-Version: 1.0 Content-Type: text/plain Can't get to searchable archives, so apologies if this has been asked before... After an upsurge in spam, decided to finally activate MX's RBL and see if it helps. The mail-abuse lists (which are the default in /RBL) are by subscription only now. Anyone have insight as to the best free service? After browsing through news postings, I decided to try relays.osirusoft.com. I'd appreciate insight from those with more experience. I also turned on all the heuristics, but those I pointed to may in-box so I can monitor manually for a bit. However, it appears the RBL checks just bounce, so I do not know if I'll get a good feel for whether it is bouncing any legitimate mail (I can see the from domain in the log but I'd feel better if I had a way to see the actual messages, at least for a while). And apparently the choice of service(s) for that is what's important. Opinions welcomed, or pointers. Linwood Ferguson Ferguson@chaslevy.com ================================================================================ Archive-Date: Mon, 4 Feb 2002 11:33:18 -0800 Date: Mon, 4 Feb 2002 22:31:06 +0300 From: rakesh@kuc01.kuniv.edu.kw Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM CC: rakesh@kuc01.kuniv.edu.kw Message-ID: <00A09154.1964B8F1.392@kuc01.kuniv.edu.kw> Subject: viruses Hello! We are using MX-5.1A. Our users report increasing number of viruses with incoming mails. Are there any programs which can be integrated with MX-5.1A running on Alpha Server with VMS 7.1 which can detect viruses with incoming mails & reject such mails or move these to some other place & later on SysAdmin could take some action on these mails & if feel appropriate release it to user & inform user or remove virus from mail & then release it to user. Best regards, RAKESH ================================================================================ Archive-Date: Mon, 4 Feb 2002 13:04:11 -0800 Subject: Re: RBL Lists From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c5ef378$1@news.kapsch.co.at> Date: 4 Feb 2002 21:47:52 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <496754D21EDBD311963800C04F012BEB48C5C9@srv-cho.CHASLEVY.com>, "Ferguson, Linwood" writes: >Can't get to searchable archives, so apologies if this has been asked >before... Yup. >After an upsurge in spam, decided to finally activate MX's RBL and see if it >helps. It does. >The mail-abuse lists (which are the default in /RBL) are by subscription >only now. Yes, MAPS (mail-abuse.org) is commercial now. But is said to be still the best one. eg the new RBL-PLUS.MAIL-ABUSE.ORG >Anyone have insight as to the best free service? We all do a little bit. Just like you... >After browsing through news postings, I decided to try relays.osirusoft.com. I decided to use RELAYS.ORDB.ORG ORBZ and SPAMCOP did block too much (in my eyes) legitimate mails. But then again, beeing listed on an RBL is the problem of the remote mail administrator, isn't it. >I'd appreciate insight from those with more experience. So do I >I also turned on all the heuristics, but those I pointed to may in-box so I >can monitor manually for a bit. However, it appears the RBL checks just >bounce, so I do not know if I'll get a good feel for whether it is bouncing >any legitimate mail (I can see the from domain in the log but I'd feel >better if I had a way to see the actual messages, at least for a while). >And apparently the choice of service(s) for that is what's important. Turn on OPCOM logging: $ df MX_EVENT_OPER_CLASS NETWORK and you see the From Adress and the IP address of the mailserver (and the name of the RBL, for the admins which use more than one). However, I know of no way to let RBL blocked mails in at all to see the rest of the mail (the header and the body). -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Mon, 4 Feb 2002 13:19:13 -0800 Subject: Re: viruses From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c5ef7f1$1@news.kapsch.co.at> Date: 4 Feb 2002 22:06:57 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <00A09154.1964B8F1.392@kuc01.kuniv.edu.kw>, rakesh@kuc01.kuniv.edu.kw writes: >We are using MX-5.1A. Our users report increasing number of viruses with >incoming mails. Are there any programs which can be integrated with >MX-5.1A running on Alpha Server with VMS 7.1 which can detect viruses with >incoming mails & reject such mails or move these to some other place & >later on SysAdmin could take some action on these mails & if feel appropriate >release it to user & inform user or remove virus from mail & then release it >to user. There are products which does all of it (eg. Content Technologies MAILsweeper) and there are virus scanners for VMS (I only know of SOPHOS - which can also be used with MAILsweeper). The combination of MX and SOPHOS and a selfwritten contentfilter with park/quarantine features is unfortunately up to you. We then would surely happy, if we can get it from you when it's ready. I do believe, that Matt would be happy if you pay him for the job, but I don't think that you want to pay the whole development alone... Most people do therfore use a virusscanner on their exchangeservers or switch away from MX to another (unfortunately most likely M$ based) SMTP server. Most of these SMTP server do unfortunately have no local userbase (eg. via LDAP - MX does offer only the VMSmail database which you must synchronize with you internal exchangeserver by hand) to block mails to unknown users at the first/only system visible from the internet (which MX _is_ able to). This is not only a performance problem as you must scan and rate them, it is also a security problem as you let the internal mailserver return the mail (if it's not a SPAM with a spoofed sender address) and accept to give internal information (like X400 notations, nodenames, ...) to the outside while many mailserver admins try to find a way to get rid of "Received:" lines on the last mail system before the internet for outgoing mails. So, in short words, it is not an easy decision... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Mon, 4 Feb 2002 13:25:54 -0800 Message-ID: <496754D21EDBD311963800C04F012BEB48C631@srv-cho.CHASLEVY.com> From: "Ferguson, Linwood" Reply-To: MX-List@MadGoat.com To: "'MX-List@MadGoat.com'" Subject: RE: RBL Lists Date: Mon, 4 Feb 2002 15:24:42 -0600 MIME-Version: 1.0 Content-Type: text/plain ON a related note, is there any way to "whitelist" a particular IP address so that it overrides the RBL? We have one (important) customer who we found out is blacklisted. All issues of "try to get them to be good citizens aside" the emphasis is on "important customer" so I can't do much other than turn off RBL. I don't see a way in MX to "whitelist" someone. Is there? Linwood ================================================================================ Archive-Date: Tue, 5 Feb 2002 02:30:44 -0800 Subject: RE: RBL Lists From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c5fb447$1@news.kapsch.co.at> Date: 5 Feb 2002 11:30:31 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <496754D21EDBD311963800C04F012BEB48C631@srv-cho.CHASLEVY.com>, "Ferguson, Linwood" writes: >ON a related note, is there any way to "whitelist" a particular IP address >so that it overrides the RBL? > >We have one (important) customer who we found out is blacklisted. All >issues of "try to get them to be good citizens aside" the emphasis is on >"important customer" so I can't do much other than turn off RBL. > >I don't see a way in MX to "whitelist" someone. Is there? Define it's mailservers address on the INSIDE_ADDRESS list and be prepared that you open a (small) security hole with this. -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Thu, 7 Feb 2002 10:40:28 -0800 Subject: Re: removing the mx% From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c62ca15$1@news.kapsch.co.at> Date: 7 Feb 2002 19:40:21 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <3c618b21$1@news.si.com>, "Brian Tillman" writes: >>However, when the email's downloaded to a PC via IUPOP3, the mx%" " remains >>on the to & cc lines, causing all the addresses to need editing on >>reply/all. > >Consider, too, asking in the IUPOP3 mailing list, available at >IUPOP3-USERS@swdev.si.com. I can't remember to have seen the original posting, but try the following logicals $ df IUPOP3_DEFAULT_TO_SMTP TRUE $ df IUPOP3_IGNORE_MAIL11_HEADERS TRUE $ df IUPOP3_USE_BOTTOM_HEADERS FALSE $ df MX_PROTOCOL_PREFIX "SMTP%" -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Thu, 7 Feb 2002 11:00:15 -0800 Message-ID: <1a6801c1b009$79e109b0$76041c7e@si.com> From: "Brian Tillman" Reply-To: MX-List@MadGoat.com To: References: <3c62ca15$1@news.kapsch.co.at> Subject: Re: removing the mx% Date: Thu, 7 Feb 2002 13:58:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >I can't remember to have seen the original posting, but >try the following logicals Here's my set, in case someone might find them useful. My mail works perfectly. Unlike Peter, I have my headers placed at the bottom and hve compiled IUPOP3 to recognize them there. It's much cleaner for my VMS Mail recipients (as few as they number at this point). "IUPOP3_APOP_CHECK_DUPLICATE" = "TRUE" "IUPOP3_AUTH_COMMANDS" = "user,apop" "IUPOP3_CLIENT_TIMEOUT" = "10" "IUPOP3_DEFAULT_SENDBUFFER_SIZE" = "8000" "IUPOP3_DEFAULT_TO_SMTP" = "TRUE" "IUPOP3_ENABLE_LONG_LINES" = "TRUE" "IUPOP3_EXE" = "IUPOP3_ROOT:[BIN]" "IUPOP3_FAST_SCAN" = "TRUE" "IUPOP3_HEADER_DELIMINATOR" = "mx" "IUPOP3_IGNORE_EXPIRED_PASSWORDS" = "TRUE" "IUPOP3_IGNORE_MAIL11_HEADERS" = "TRUE" "IUPOP3_LOG" = "IUPOP3_ROOT:[LOG]" "IUPOP3_MAIL_RECIPIENTS" = "TILLMAN" "IUPOP3_MAX_MESSAGES" = "4096" "IUPOP3_NODE_SWDEV" = "swdev.si.com" "IUPOP3_PERSONAL_NAME" = "TRUE" "IUPOP3_PURGE_MAILBOXES" = "TRUE" "IUPOP3_PURGE_RECLAIM_THRESHOLD" = "32000" "IUPOP3_READ_DIRECT_THRESHOLD" = "1364992" "IUPOP3_ROOT" = "POP_DISK:[IUPOP3.]" "IUPOP3_SCAN_INTRUSION" = "TRUE" "IUPOP3_USE_BOTTOM_HEADERS" = "TRUE" "IUPOP3_USE_MAIL_FOLDER" = "FALSE" Brian Tillman Internet: tillman_brian at si.com Smiths Aerospace tillman at swdev.si.com 3290 Patterson Ave. SE, MS Addresses modified to prevent Grand Rapids, MI 49512-1991 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. *********************************************************************** ================================================================================ Archive-Date: Mon, 11 Feb 2002 11:01:25 -0800 Message-ID: <3C6814FA.B3F1ADC3@montana.edu> Date: Mon, 11 Feb 2002 12:01:14 -0700 From: Allen Porter Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: mx-list@madgoat.com Subject: List Member is Stronger Than List Owner? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have been perplexed by a situation lately, but have finally gotten to the bottom of it. A list owner has been posting to a list, with no problems, where some of the set of list members (generated automatically) are added to the list as NOPOST. All of a sudden he could not post to the list -- and I finally discovered that he had joined the set of members that are added to the list as NOPOST. It seems that the member list is checked first and his address being found results in him not being able to post to the list, even though he is an owner and owners have posting privileges. It seems that being an owner should be a stronger privilege. Comments, anyone? Allen Porter Montana State University ahporter@montana.edu ================================================================================ Archive-Date: Mon, 11 Feb 2002 14:38:35 -0800 Message-ID: <3C684032.80705387@montana.edu> Date: Mon, 11 Feb 2002 15:05:38 -0700 From: Allen Porter Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: mx-list@madgoat.com Subject: /NOIGNORE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The MX v5.2 MCP command "show list/command" has as its last command a "/NOIGNORE". Unfortunately, it does not like this negated qualifier. -- Allen H Porter ahporter@montana.edu Information Technology Center Montana State University-Bozeman Phone (406)994-5088 PO Box 173240, Bozeman, MT 59717-3240 FAX (406)994-4600 ================================================================================ Archive-Date: Tue, 12 Feb 2002 13:38:44 -0800 Subject: Re: Is RBL useful behind a firewall? From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c6976e4$1@news.kapsch.co.at> Date: 12 Feb 2002 21:11:16 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <3c6962a5$1@news.si.com>, "Brian Tillman" writes: >Our VMS system is behind a company firewall. In fact, it's behind a mail >scanner. (I.e., mail routes from firewall to scanner to destination >machines). Under these conditions, I didn't think enabling the RBL checking >would be of much value for the VMS-based recipients because the only machine >actually sending mail to VMS is the scanner system. Doesn't the SMTP >handshake (MAIL FROM, RCPT TO) include only the scanner machine or is the >original sender reflected in the MAIL FROM? The original sender is the MAIL FROM. A part of the RFC[2]821 info. So what do you mean ? The IP address of the sending mailserver ? This should be entered in the RFC[2]822 headers via the Received From: line. But to block mails based on this info, I think it is too late. Blocking should happen as a rejection on the outtermost mailserver. In all other cases you already took the responsibility of the delivery of the [blocked] mails and this problem could lead to big headaches in a big company with many thousand mails a day. So, RBL should be running on your scanner - or change the position of your scanner and MX and make MX your outtermost mailserver. Another problem is the mailuserdatabase. Most mailscannners do policies based on eg. mailboxaddresses but rejections are rarely found in such scanners. And if mails for non-existant (or no longer existing) mailboxes get accepted by the outtermost mailscanners, it is the duty of the eg. mailboxserver to get the message back to the recipient because of "no such user". And this mail does usually give additional infos about internal structures like X400 items or mailserver nodenames. In a time where security gots more and more important (eg. mailservers get features to remove all Received From: lines from all outgoing mails - security through obscurity), this is very counterproductive. Can you rephrase your question ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 13 Feb 2002 06:38:38 -0800 Message-ID: <02b301c1b499$82c662c0$76041c7e@si.com> From: "Brian Tillman" Reply-To: MX-List@MadGoat.com To: References: <3c6976e4$1@news.kapsch.co.at> Subject: Re: Is RBL useful behind a firewall? Date: Wed, 13 Feb 2002 09:19:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >The original sender is the MAIL FROM. A part of the RFC[2]821 info. >So what do you mean ? The IP address of the sending mailserver ? >This should be entered in the RFC[2]822 headers via the Received From: line. I was under the impression (apparently incorrect) that, if mail is routed from A to B to C that A would say to B MAIL FROM someone@a and that B would say to C MAIL FROM someone@b, but what you say is that the MAIL FROM address is carried through from machine to machine. Correct? >But to block mails based on this info, I think it is too late. >Blocking should happen as a rejection on the outtermost mailserver. Why? What difference does it make where, prior to the final delivery, a message is blocked, as long as it _is_ blocked when appropriate. The outermost mail server may not have the intelligence to do the blocking. In our case, that's why we have a scanner inside our firewall. The firewall doesn't run enough of an operating system to do anything other than firewalling. >In all other cases you already took the responsibility of the delivery of >the [blocked] mails and this problem could lead to big headaches in a big >company with many thousand mails a day. Nonsense. We block, on average, 75,000 messages per month after they've been accepted by the firewall. The scanner dumps them in the bit bucket. >So, RBL should be running on your >scanner While the scanner can reference RBL, it can only reference MAPS and since that's a pay service now, it's useless. >or change the position of your scanner and MX and make MX your >outtermost mailserver. Can't do that, although I'd like to. Politics. >Another problem is the mailuserdatabase. Most mailscannners do policies >based on eg. mailboxaddresses but rejections are rarely found in such scanners. I don't understand this sentence. Our scanner can reject based on the envelope from/to, the header from/to, the content of the subject, or the content of the message itself. The newest release can filter on any of the headers in additon. Brian Tillman Internet: tillman_brian at si.com Smiths Aerospace tillman at swdev.si.com 3290 Patterson Ave. SE, MS Addresses modified to prevent Grand Rapids, MI 49512-1991 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. *********************************************************************** ================================================================================ Archive-Date: Wed, 13 Feb 2002 08:08:03 -0800 Subject: Re: Is RBL useful behind a firewall? From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c6a8f57$1@news.kapsch.co.at> Date: 13 Feb 2002 17:07:51 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <02b301c1b499$82c662c0$76041c7e@si.com>, "Brian Tillman" writes: >>The original sender is the MAIL FROM. A part of the RFC[2]821 info. >>So what do you mean ? The IP address of the sending mailserver ? >>This should be entered in the RFC[2]822 headers via the Received From: >line. > >I was under the impression (apparently incorrect) that, if mail is routed >from A to B to C that A would say to B MAIL FROM someone@a and that B would >say to C MAIL FROM someone@b, but what you say is that the MAIL FROM address >is carried through from machine to machine. Correct? Yup. >>But to block mails based on this info, I think it is too late. >>Blocking should happen as a rejection on the outtermost mailserver. > >Why? What difference does it make where, prior to the final delivery, a >message is blocked, as long as it _is_ blocked when appropriate. The >outermost mail server may not have the intelligence to do the blocking. In >our case, that's why we have a scanner inside our firewall. The firewall >doesn't run enough of an operating system to do anything other than >firewalling. Blocking versus rejecting is the key. Rejecting means you don't accept the mail at all, leave the return-to-the-sender problem or the must-deliver-it-to-the-postmaster problem up to the remote mailserver (admin). >>In all other cases you already took the responsibility of the delivery of >>the [blocked] mails and this problem could lead to big headaches in a big >>company with many thousand mails a day. > >Nonsense. We block, on average, 75,000 messages per month after they've >been accepted by the firewall. The scanner dumps them in the bit bucket. And what do you do then with them ? Simply discard them ? Or check them by hand to look for possible reasonable mails filtered on accident ? Despite the bandwith save by not accepting these mails, it saves a lot of the postmaster's time if you don't accept the duty of delivery of ALL the mails. RBL is also such a method of not accepting the mail at all, leaving the SPAMmer with the problem, what to do with the mails. >>So, RBL should be running on your >>scanner > >While the scanner can reference RBL, it can only reference MAPS and since >that's a pay service now, it's useless. That's unfortunate. We see also, such scanners lag behind MX. Eg. no RBL at all, or only one RBL, or RBL not configurable, or RBL configurable but rejection message not configurable (and wrong). And why not paying for MAPS ? Personally I think, it is worth the price (but my company has so far another opinion). >>or change the position of your scanner and MX and make MX your >>outtermost mailserver. > >Can't do that, although I'd like to. Politics. As we can see everywhere... >>Another problem is the mailuserdatabase. Most mailscannners do policies >>based on eg. mailboxaddresses but rejections are rarely found in such >>scanners. > >I don't understand this sentence. Our scanner can reject based on the >envelope from/to, the header from/to, the content of the subject, or the >content of the message itself. The newest release can filter on any of the >headers in additon. If you can REJECT (means abort the transfer with a reasonable/configurable error message during the message gets in), you already got a useful scanner. Most can only BLOCK/FILTER them and eg. park them in a qurantine area, leaving YOU to find out what to do with this mail messages... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 13 Feb 2002 09:08:56 -0800 Message-ID: <063801c1b4b0$ef6015e0$76041c7e@si.com> From: "Brian Tillman" Reply-To: MX-List@MadGoat.com To: References: <3c6a8f57$1@news.kapsch.co.at> Subject: Re: Is RBL useful behind a firewall? Date: Wed, 13 Feb 2002 12:07:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >Blocking versus rejecting is the key. Rejecting means you don't accept >the mail at all, leave the return-to-the-sender problem or the >must-deliver-it-to-the-postmaster problem up to the remote mailserver (admin). We block them, not reject them, if I catch your meaning. In other words, the mail is silently tossed. No messages back to the sending system. >And what do you do then with them ? Simply discard them ? Or check them >by hand to look for possible reasonable mails filtered on accident ? Usually just discard them. Periodically, I'll have the mail system forward them to me for a few days just to make sure we're not tossing valid messages. If I come across any, I modify the scanner to be more lenient. >If you can REJECT (means abort the transfer with a reasonable/configurable >error message during the message gets in), you already got a useful scanner. >Most can only BLOCK/FILTER them and eg. park them in a qurantine area, leaving >YOU to find out what to do with this mail messages... It _can_ do both, but typically we don't reject, just block. The firewall can be told to reject messages from specified IP addresses, but even those instances (like mail from the *.seed.net.tw systems), we just silently discard the messages. Rejecting them would do no good because the SPAMmer systems just ignore the rejections. Brian Tillman Internet: tillman_brian at si.com Smiths Aerospace tillman at swdev.si.com 3290 Patterson Ave. SE, MS Addresses modified to prevent Grand Rapids, MI 49512-1991 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. *********************************************************************** ================================================================================ Archive-Date: Wed, 20 Feb 2002 12:14:14 -0800 Subject: Stupid question on MTA error messages From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c740388$1@news.kapsch.co.at> Date: 20 Feb 2002 21:14:00 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com May I ask a probably stupid question ? Where is a list of the possible error message codes of MTAs in general and/or especially MX documented ? Is there a RFC ? I'm looking for an "#5.3.3" and seem unlucky so far... Reason is, that M$ DSN does not include the MTA reply code or the additional text (which eventually lead to an Anti-SPAM rule) and so the user and (much later) myself is stumped. Eine kritische Funktion, die zur Übermittlung der Nachricht erforderlich ist, wurde vom Absender des Berichts nicht unterstützt. Die MTS-ID der ursprünglichen Nachricht ist: c=AT;a=ADA;p=Kapsch AG;l=DUMBO0201220852160307 TIA -Peter PS: You can find the list of MTA reply codes in (RFC821 and now in) RFC2821: 4.2.3 Reply Codes in Numeric Order 211 System status, or system help reply 214 Help message (Information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user) 220 Service ready 221 Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to (See section 3.4) 252 Cannot VRFY user, but will accept message and attempt delivery (See section 3.5.3) 354 Start mail input; end with . 421 Service not available, closing transmission channel (This may be a reply to any command if the service knows it must shut down) 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy) 451 Requested action aborted: local error in processing 452 Requested action not taken: insufficient system storage 500 Syntax error, command unrecognized (This may include errors such as command line too long) 501 Syntax error in parameters or arguments 502 Command not implemented (see section 4.2.4) 503 Bad sequence of commands 504 Command parameter not implemented 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 551 User not local; please try (See section 3.4) 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") The RFC2821 is relatively new (April 2001). Matt, did you check the new reply code (I think: 252) already into MX ? Does this make sense at all ? -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 20 Feb 2002 12:43:14 -0800 From: "Esa Laitinen" To: MX-List@MadGoat.com Date: Wed, 20 Feb 2002 22:43:36 +0200 MIME-Version: 1.0 Subject: Re: Stupid question on MTA error messages Reply-To: MX-List@MadGoat.com Message-ID: <3C742698.13494.A32C8EF@localhost> In-Reply-To: <3c740388$1@news.kapsch.co.at> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Description: Mail message body On 20 Feb 2002 at 21:14, Peter LANGSTOEGER wrote: > Where is a list of the possible error message codes of MTAs in general > and/or especially MX documented ? Is there a RFC ? Check out - http://www.faqs.org/rfcs/rfc1893.html (Enhanced Mail System Status Codes) - http://www.landfield.com/rfcs/rfc2034.html (SMTP Service Extension for Returning Enhanced Error Codes) -http://www.faqs.org/rfcs/rfc1894.html (An Extensible Message Format for Delivery Status Notifications) It is the first one that contains the actual codes. Yours, esa ps. I had to search long for these documents when first encountering a similar problem, so IMHO the question wasn't stupid ;-) ================================================================================ Archive-Date: Wed, 20 Feb 2002 13:10:25 -0800 Subject: Re: Stupid question on MTA error messages From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c740ff5$1@news.kapsch.co.at> Date: 20 Feb 2002 22:07:01 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <3C742698.13494.A32C8EF@localhost>, "Esa Laitinen" writes: >On 20 Feb 2002 at 21:14, Peter LANGSTOEGER wrote: >> Where is a list of the possible error message codes of MTAs in general >> and/or especially MX documented ? Is there a RFC ? > >Check out >- http://www.faqs.org/rfcs/rfc1893.html (Enhanced Mail System Status Codes) >- http://www.landfield.com/rfcs/rfc2034.html (SMTP Service Extension for >Returning Enhanced Error Codes) >-http://www.faqs.org/rfcs/rfc1894.html (An Extensible Message Format for >Delivery Status Notifications) >It is the first one that contains the actual codes. >Yours, > >esa >ps. I had to search long for these documents when first encountering a similar >problem, so IMHO the question wasn't stupid ;-) Thanks a lot for this fast reponse (and for your opinion ;-) Indeed, the rfc1893 was exactly was I was after. And it states: X.3.3 System not capable of selected features Selected features specified for the message are not supported by the destination system. This can occur in gateways when features from one domain cannot be mapped onto the supported feature in another. where X=5 means the error is permanent So, does anyone (Matt ?) know, what feature of MX could cause this ? Anti-SPAM? Without additional info (eg. another rejected mail with OPCOM messages or a trace) I'm still stumped... TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Thu, 21 Feb 2002 04:38:00 -0800 Subject: MX LOCAL and -RMS-E-FLK, file currently locked byanother user From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c74e400@news.kapsch.co.at> Date: 21 Feb 2002 13:11:44 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Matt, may I ask you (again), that the MX LOCAL agent be fixed (again). A MAIL>PURGE (or in real MAIL>EXIT with AUTOPURGE enabled) locks the MAIL.MAI (-RMS-E-FLK, file currently locked byanother user) for a couple of (milli)seconds and MX LOCAL then cannot deliver a mail. But instead of retrying it for the next couple of times/hours (like eg. when diskquota is exceeded), it returns it to the sender immediately which is absolutely not what I'd expected. Many TIA -Peter -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Thu, 21 Feb 2002 05:54:51 -0800 Date: Thu, 21 Feb 2002 05:54:47 -0800 From: Matt Madison Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <00A09E24.BB9ABAF6.2@MadGoat.Com> Subject: RE: MX LOCAL and -RMS-E-FLK, file currently locked byanother user MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" >Matt, may I ask you (again), that the MX LOCAL agent be fixed (again). > >A MAIL>PURGE (or in real MAIL>EXIT with AUTOPURGE enabled) >locks the MAIL.MAI (-RMS-E-FLK, file currently locked byanother user) >for a couple of (milli)seconds and MX LOCAL then cannot deliver a mail. > >But instead of retrying it for the next couple of times/hours (like eg. >when diskquota is exceeded), it returns it to the sender immediately >which is absolutely not what I'd expected. I'll get it right one of these times... should be fixed (again) in the next release, which will be going to beta in the next few days. -Matt -- Matthew Madison | MadGoat Software | PO Box 556, Santa Cruz, CA 95061 USA madison@madgoat.com http://www.madgoat.com ================================================================================ Archive-Date: Sun, 24 Feb 2002 02:26:53 -0800 Subject: PIR From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3c78bf60$1@news.kapsch.co.at> Date: 24 Feb 2002 11:24:32 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com I'd like to request an product improvement for/of MX: DSN messages (eg. of an M$ exchange server) are generated with sender "<>". When such messages are sent through MX and are then not deliverable, MX simply discards them. They are not delivered to MX's postmaster, no matter what the setting "Local delivery errors are CC'ed to local Postmaster" is. I'd like to have this behaviour fixed/controllable. TIA -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111 2651 Network and OpenVMS system manager Fax. +43 1 81111 888 KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Sun, 24 Feb 2002 13:11:02 -0800 From: "Esa Laitinen" To: MX-List@MadGoat.com Date: Sun, 24 Feb 2002 23:11:21 +0200 MIME-Version: 1.0 Subject: Re: PIR Reply-To: MX-List@MadGoat.com Message-ID: <3C797319.368.6EAE363@localhost> In-Reply-To: <3c78bf60$1@news.kapsch.co.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable Content-Description: Mail message body On 24 Feb 2002 at 11:24, Peter LANGSTOEGER wrote: > DSN messages (eg. of an M$ exchange server) are generated with sender "<= >". > When such messages are sent through MX and are then not deliverable, MX > simply discards them. They are not delivered to MX's postmaster, no matt= er > what the setting "Local delivery errors are CC'ed to local Postmaster" i= s. > > I'd like to have this behaviour fixed/controllable. If implemented it should be controllable. You'd be opening yourself up for= a DoS attack: somebody forges your domain in their spamrun (sent by imaginary us= ers from your domain). The bounces come back to your imaginary users (there are a = huge percentage of undeliverables in a normal spamrun) with sender <>. It is ba= d enough to waste the bandwith, it is even worse to clean up postmaster's mailbox a= fterwards (you'd be running out of diskquota if not diskspace). Just my .02=80 esa