IBM-MAIN subscription
> I cannot imagine any technical or policy reason for leaving that field blank. > It has Omission written all over it. > This problem affects multiple shops. If should be fixed at the source. The latest revision of the SMTP RFCs (RFC 5821) do address this issue somewhat, to wit: 4.5.5 Messages with a Null Reverse-Path There are several types of notification messages that are required by existing and proposed Standards to be sent with a null reverse-path, namely non-delivery notifications as discussed in Section 3.7, other kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and Message Disposition Notifications (MDNs, RFC 3798 [37]). All of these kinds of messages are notifications about a previous message, and they are sent to the reverse-path of the previous mail message. (If the delivery of such a notification message fails, that usually indicates a problem with the mail system of the host to which the notification message is addressed. For this reason, at some hosts the MTA is set up to forward such failed notification messages to someone who is able to fix problems with the mail system, e.g., via the postmaster alias.) All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path. Implementers of automated email processors should be careful to make sure that the various kinds of messages with a null reverse-path are handled correctly. so it comes down to handling of failed non-delivery notifications to prevent mail loops as the primary reasons to permit null paths. Excluding all null reverse paths breaks an important function of the underlying protocol, but the sheer scale of the Internet makes it difficult to implement anything quickly. (Note that none of the IBM supported implementations (other than sendmail) support any of this -- just our small part of the world doesn't handle this, so expecting the larger universe to conform to us is unlikely. The fact that email works at all after 30+ years is a pretty impressive display of backward compatibility.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
On 2017-02-12, at 15:56, Jesse 1 Robinson wrote: > > I cannot imagine any technical or policy reason for leaving that field blank. > It has Omission written all over it. This problem affects multiple shops. If > should be fixed at the source. > From RFC 822: 4.4.1. FROM / RESENT-FROM This field contains the identity of the person(s) who wished this message to be sent. The message-creation process should default this field to be a single, authenticated machine address, indicating the AGENT (person, system or process) entering the message. If this is not done, the "Sender" field MUST be present. If the "From" field IS defaulted this way, the "Sender" field is optional and is redundant with the "From" field. In all cases, addresses in the "From" field must be machine-usable (addr-specs) and may not contain named lists (groups). 4.4.2. SENDER / RESENT-SENDER This field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the mes- sage, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field... (Emphasis added, I hope.) And in RFC 2822: ... If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. So LISTSERV is following the recommendation (... discouraged ... SHOULD NOT ... ) and your MTA seems to be deviating. But in other contexts, experts have said that the venerable standards invite threats and must be disobeyed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
On 2017-02-12, at 15:56, Jesse 1 Robinson wrote: > I'm fully on board with "Subscription=Open,Confirm" if it makes email safer > in general. What frosts me is that the "D" of WAD misses the mark and is > actually counterproductive. I'm told (!) that we have implemented what we > lovingly call 'industry best practice' in quarantining any email with no > sender specified. It does not matter what the sender field contains; it just > cannot be blank. So send the confirmation note with something--anything--in > that field, and all will be well. > > I cannot imagine any technical or policy reason for leaving that field blank. > It has Omission written all over it. This problem affects multiple shops. If > should be fixed at the source. > I see that, as you said, messages posted to IBM-MAIN have "Sender:"; confirmation requests lack it. Can you or your email tech retrieve *just*one* confirmation request from quarantine so you can confirm, they you'll be home free? (TSO-REXX is the same way.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
I'm fully on board with "Subscription=Open,Confirm" if it makes email safer in general. What frosts me is that the "D" of WAD misses the mark and is actually counterproductive. I'm told (!) that we have implemented what we lovingly call 'industry best practice' in quarantining any email with no sender specified. It does not matter what the sender field contains; it just cannot be blank. So send the confirmation note with something--anything--in that field, and all will be well. I cannot imagine any technical or policy reason for leaving that field blank. It has Omission written all over it. This problem affects multiple shops. If should be fixed at the source. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Boyes Sent: Sunday, February 12, 2017 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):IBM-MAIN subscription > No closer to a resolution. I have verified with our email staff that the > IBM-MAIN confirmation email arrives here with no sender specified. >This makes the note indistinguishable from scatter spam and causes immediate >quarantine, so I never see it. > By contrast, I just (re)subscribed to the TSO-REXX list at Marist. >Notes came back to my inbox, although there seems to be no actual >confirmation message. One conspicuous difference is that the UA List Server >software says 16.0, while the Marist notes indicate 14.4. > According to Gil, only the licensee can open an issue with L-Soft. The key option in the list definition is " Subscription= Open,Confirm". The problem is triggered by the ",Confirm" option - the problem messages are generated by the logic backing that option. Downside of removing this is that removing it would allow "drive-by" lusers to subscribe, send spam, and unsubscribe, and the spammer community actively looks for this kind of thing. (FWIW, requests for IBM-MAIN subscriptions sent to Marist or any other LISTSERV site are automagically forwarded to listserv.ua.edu, so the problem is still present in the code that UA.EDU runs). Speculation: I suspect the response to any bug report here will be closed WAD (working as designed). When Eric Thomas introduced the confirmation logic to LISTSERV, I argued with him about this implementation (jeez, has it really been 20+ years ago?). His response was something to the effect of "RFCs explicitly require accepting messages with this construct (the null MAIL FROM: line), and LISTSERV will comply with that." I doubt he's changed his mind over the intervening years, and there are external standards that support his implementation (RFC 2505, for example). If you run sendmail on your mail server(or as a front end to another SMTP implementation), I can give you a snippet of M4 code that you can insert into your sendmail.cf that will rewrite a null MAIL FROM into an address of your choice (no-reply@yourdomain, or something similar). Can't do anything about the other SMTP daemons, and it breaks some of the other logic in LISTSERV's assumptions, but it does allow your email guys to not open up any new holes in their armor. If you combine that with a procmail script that responds to the no-reply address with the instructions on how to respond to LISTSERV verification messages, you've got it as covered as it is going to be. Another thing: ask your email guys if they have implemented SPF lookups for your mail system. Won't fix the MAIL FROM problem by itself, but goes a long way to making it really hard to forge messages coming in for random domains (SPF allows mail systems to declare what mail servers are "official" for a domain in the DNS and for others to verify that the email is coming from the official servers only). That may make your email guys willing to relax their rules about null MAIL FROMs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM-MAIN subscription
> No closer to a resolution. I have verified with our email staff that the > IBM-MAIN confirmation email arrives here with no sender specified. >This makes the note indistinguishable from scatter spam and causes immediate >quarantine, so I never see it. > By contrast, I just (re)subscribed to the TSO-REXX list at Marist. Notes came > back to my inbox, although there seems to be no actual > confirmation message. One conspicuous difference is that the UA List Server > software says 16.0, while the Marist notes indicate 14.4. > According to Gil, only the licensee can open an issue with L-Soft. The key option in the list definition is " Subscription= Open,Confirm". The problem is triggered by the ",Confirm" option - the problem messages are generated by the logic backing that option. Downside of removing this is that removing it would allow "drive-by" lusers to subscribe, send spam, and unsubscribe, and the spammer community actively looks for this kind of thing. (FWIW, requests for IBM-MAIN subscriptions sent to Marist or any other LISTSERV site are automagically forwarded to listserv.ua.edu, so the problem is still present in the code that UA.EDU runs). Speculation: I suspect the response to any bug report here will be closed WAD (working as designed). When Eric Thomas introduced the confirmation logic to LISTSERV, I argued with him about this implementation (jeez, has it really been 20+ years ago?). His response was something to the effect of "RFCs explicitly require accepting messages with this construct (the null MAIL FROM: line), and LISTSERV will comply with that." I doubt he's changed his mind over the intervening years, and there are external standards that support his implementation (RFC 2505, for example). If you run sendmail on your mail server(or as a front end to another SMTP implementation), I can give you a snippet of M4 code that you can insert into your sendmail.cf that will rewrite a null MAIL FROM into an address of your choice (no-reply@yourdomain, or something similar). Can't do anything about the other SMTP daemons, and it breaks some of the other logic in LISTSERV's assumptions, but it does allow your email guys to not open up any new holes in their armor. If you combine that with a procmail script that responds to the no-reply address with the instructions on how to respond to LISTSERV verification messages, you've got it as covered as it is going to be. Another thing: ask your email guys if they have implemented SPF lookups for your mail system. Won't fix the MAIL FROM problem by itself, but goes a long way to making it really hard to forge messages coming in for random domains (SPF allows mail systems to declare what mail servers are "official" for a domain in the DNS and for others to verify that the email is coming from the official servers only). That may make your email guys willing to relax their rules about null MAIL FROMs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
No closer to a resolution. I have verified with our email staff that the IBM-MAIN confirmation email arrives here with no sender specified. This makes the note indistinguishable from scatter spam and causes immediate quarantine, so I never see it. By contrast, I just (re)subscribed to the TSO-REXX list at Marist. Notes came back to my inbox, although there seems to be no actual confirmation message. One conspicuous difference is that the UA List Server software says 16.0, while the Marist notes indicate 14.4. According to Gil, only the licensee can open an issue with L-Soft. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, February 02, 2017 2:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBM-MAIN subscription On 2017-02-02, at 12:13, Jesse 1 Robinson wrote: > My email tech just verified that the confirmation notes (only!) 'do not have > a valid sender email address' and therefore get quarantined by our email > system. Deleted after 4 days. Since other(s) seem to also have this problem, > I think a fix to List Server 16.0 would be in order. > In order, but unlikely. For years I have complained to list owners that when I attempt to Reply via the web interface and quote the original message which happens to be base64 encoded (as yours is), the quote command fetches unrendered base4. No resolution (but the list owners have never acknowleged the report). And L-Soft requires a customer ID to submit an SR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
On 2017-02-02, at 12:13, Jesse 1 Robinson wrote: > My email tech just verified that the confirmation notes (only!) 'do not have > a valid sender email address' and therefore get quarantined by our email > system. Deleted after 4 days. Since other(s) seem to also have this problem, > I think a fix to List Server 16.0 would be in order. > In order, but unlikely. For years I have complained to list owners that when I attempt to Reply via the web interface and quote the original message which happens to be base64 encoded (as yours is), the quote command fetches unrendered base4. No resolution (but the list owners have never acknowleged the report). And L-Soft requires a customer ID to submit an SR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
My email tech just verified that the confirmation notes (only!) 'do not have a valid sender email address' and therefore get quarantined by our email system. Deleted after 4 days. Since other(s) seem to also have this problem, I think a fix to List Server 16.0 would be in order. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Sunday, January 29, 2017 12:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBM-MAIN subscription How about FROM: <n...@none.com>, or FROM: <nore...@listserv.ua.edu>? On Sat, Jan 28, 2017 at 8:04 PM, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > Thanks David for this illumination. All we're looking for is some kind of > nonblank FROM <> value that passes validation on the receiving side. My > internal PMR is still open, but I'm expecting this to be the diagnosis. > Without knowing any of the internals, I can verify that other list servers > like ISPF-L and TSO-REXX seem to get around this problem somehow. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of David Boyes > Sent: Saturday, January 28, 2017 5:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):IBM-MAIN subscription > >>My analysis: There is something missing in the confirmation email that >>causes my company email system (Outlook) to reject the note as spam > >>without notification. My home email does not have the same filter. I >>cannot look at headers for the failing notes because--I never get them. >>My > >>earlier explanation is from memory of a past conversation with an >>email tech who was able to look at a rejected note. I don't recall the >>exact > >>missing tag(s). > > > > It's actually on the mail server itself, not the client. This is another one > caused by "the spec says X, but real life has proved that this was OK in > theory but not so great in practice, so it's now forbidden by most common > implementations". > > > > When you send a subscribe request to any list managed by Lsoft's LISTSERV > (like this one), the server responds with a message constructed to have a > MAIL FROM: <> as part of the SMTP envelope. This was originally put in the > spec to handle mail generated by any kind of robot/automated responder - > there's no human to respond to the notification, so the response is sent with > an empty source address. > > > > Unfortunately, this became widely used by spammers and DoS attacks so they > wouldn't have to fake a believable From address for each mail, so most modern > implementations now reject anything with a MAIL FROM: <> line. (As a side > note, this is the first case of this kind of operational filtering via code > implemented in the common SMTP daemons - the DNS requirement was added on for > the same reason). > > > > You can test this by doing: > > > > telnet your.mail.server 25 > > HELO foo > > MAIL FROM: <> > > > > You should get an error message at this point. > > > > There's a list of these techniques and "agreements" in a modern email system > in RFC2505. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
How about FROM: <n...@none.com>, or FROM: <nore...@listserv.ua.edu>? On Sat, Jan 28, 2017 at 8:04 PM, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > Thanks David for this illumination. All we're looking for is some kind of > nonblank FROM <> value that passes validation on the receiving side. My > internal PMR is still open, but I'm expecting this to be the diagnosis. > Without knowing any of the internals, I can verify that other list servers > like ISPF-L and TSO-REXX seem to get around this problem somehow. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Boyes > Sent: Saturday, January 28, 2017 5:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):IBM-MAIN subscription > >>My analysis: There is something missing in the confirmation email that >>causes my company email system (Outlook) to reject the note as spam > >>without notification. My home email does not have the same filter. I >>cannot look at headers for the failing notes because--I never get them. >>My > >>earlier explanation is from memory of a past conversation with an email >>tech who was able to look at a rejected note. I don't recall the exact > >>missing tag(s). > > > > It's actually on the mail server itself, not the client. This is another one > caused by "the spec says X, but real life has proved that this was OK in > theory but not so great in practice, so it's now forbidden by most common > implementations". > > > > When you send a subscribe request to any list managed by Lsoft's LISTSERV > (like this one), the server responds with a message constructed to have a > MAIL FROM: <> as part of the SMTP envelope. This was originally put in the > spec to handle mail generated by any kind of robot/automated responder - > there's no human to respond to the notification, so the response is sent with > an empty source address. > > > > Unfortunately, this became widely used by spammers and DoS attacks so they > wouldn't have to fake a believable From address for each mail, so most modern > implementations now reject anything with a MAIL FROM: <> line. (As a side > note, this is the first case of this kind of operational filtering via code > implemented in the common SMTP daemons - the DNS requirement was added on for > the same reason). > > > > You can test this by doing: > > > > telnet your.mail.server 25 > > HELO foo > > MAIL FROM: <> > > > > You should get an error message at this point. > > > > There's a list of these techniques and "agreements" in a modern email system > in RFC2505. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription
Thanks David for this illumination. All we're looking for is some kind of nonblank FROM <> value that passes validation on the receiving side. My internal PMR is still open, but I'm expecting this to be the diagnosis. Without knowing any of the internals, I can verify that other list servers like ISPF-L and TSO-REXX seem to get around this problem somehow. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Boyes Sent: Saturday, January 28, 2017 5:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):IBM-MAIN subscription >My analysis: There is something missing in the confirmation email that >causes my company email system (Outlook) to reject the note as spam >without notification. My home email does not have the same filter. I >cannot look at headers for the failing notes because--I never get them. >My >earlier explanation is from memory of a past conversation with an email >tech who was able to look at a rejected note. I don't recall the exact >missing tag(s). It's actually on the mail server itself, not the client. This is another one caused by "the spec says X, but real life has proved that this was OK in theory but not so great in practice, so it's now forbidden by most common implementations". When you send a subscribe request to any list managed by Lsoft's LISTSERV (like this one), the server responds with a message constructed to have a MAIL FROM: <> as part of the SMTP envelope. This was originally put in the spec to handle mail generated by any kind of robot/automated responder - there's no human to respond to the notification, so the response is sent with an empty source address. Unfortunately, this became widely used by spammers and DoS attacks so they wouldn't have to fake a believable From address for each mail, so most modern implementations now reject anything with a MAIL FROM: <> line. (As a side note, this is the first case of this kind of operational filtering via code implemented in the common SMTP daemons - the DNS requirement was added on for the same reason). You can test this by doing: telnet your.mail.server 25 HELO foo MAIL FROM: <> You should get an error message at this point. There's a list of these techniques and "agreements" in a modern email system in RFC2505. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM-MAIN subscription
>My analysis: There is something missing in the confirmation email that causes >my company email system (Outlook) to reject the note as spam >without notification. My home email does not have the same filter. I cannot >look at headers for the failing notes because--I never get them. My >earlier explanation is from memory of a past conversation with an email tech >who was able to look at a rejected note. I don't recall the exact >missing tag(s). It's actually on the mail server itself, not the client. This is another one caused by "the spec says X, but real life has proved that this was OK in theory but not so great in practice, so it's now forbidden by most common implementations". When you send a subscribe request to any list managed by Lsoft's LISTSERV (like this one), the server responds with a message constructed to have a MAIL FROM: <> as part of the SMTP envelope. This was originally put in the spec to handle mail generated by any kind of robot/automated responder - there's no human to respond to the notification, so the response is sent with an empty source address. Unfortunately, this became widely used by spammers and DoS attacks so they wouldn't have to fake a believable From address for each mail, so most modern implementations now reject anything with a MAIL FROM: <> line. (As a side note, this is the first case of this kind of operational filtering via code implemented in the common SMTP daemons - the DNS requirement was added on for the same reason). You can test this by doing: telnet your.mail.server 25 HELO foo MAIL FROM: <> You should get an error message at this point. There's a list of these techniques and "agreements" in a modern email system in RFC2505. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription (was HMC Mail domain)
That would be great if you could do that. We have the same problem here with newer folks trying to subscribe. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Friday, January 27, 2017 1:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM-MAIN subscription (was HMC Mail domain) That is my current company email situation. It may seem heavy handed, but notes deemed to be spam are simply flushed. My predefined Junk folder contains only what I put there by inbox rule. I can take the issue back to the email guru who originally diagnosed the problem if there's some hope of finding a generalized solution. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, January 27, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBM-MAIN subscription (was HMC Mail domain) At two places I worded at, one using Lotus Notes I never see Junk mail and some good mail unless I call the help desk and now here, currently MS-OE some mail deemed as junk never gets to me, they use a google service to weed out junk, and i get a quarantine email message telling me what emails was not delivered and an option to mark as not spam - Original Message - From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, January 27, 2017 12:25:37 PM Subject: Re: IBM-MAIN subscription (was HMC Mail domain) On Fri, 27 Jan 2017 17:01:58 +, Jesse 1 Robinson wrote: >My analysis: There is something missing in the confirmation email that causes >my company email system (Outlook) to reject the note as spam without >notification. And it didn't go into your Junk folder? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription (was HMC Mail domain)
That is my current company email situation. It may seem heavy handed, but notes deemed to be spam are simply flushed. My predefined Junk folder contains only what I put there by inbox rule. I can take the issue back to the email guru who originally diagnosed the problem if there's some hope of finding a generalized solution. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, January 27, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBM-MAIN subscription (was HMC Mail domain) At two places I worded at, one using Lotus Notes I never see Junk mail and some good mail unless I call the help desk and now here, currently MS-OE some mail deemed as junk never gets to me, they use a google service to weed out junk, and i get a quarantine email message telling me what emails was not delivered and an option to mark as not spam - Original Message - From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, January 27, 2017 12:25:37 PM Subject: Re: IBM-MAIN subscription (was HMC Mail domain) On Fri, 27 Jan 2017 17:01:58 +, Jesse 1 Robinson wrote: >My analysis: There is something missing in the confirmation email that causes >my company email system (Outlook) to reject the note as spam without >notification. And it didn't go into your Junk folder? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription (was HMC Mail domain)
There is a lot of things that can happen: - the sender may be blacklisted (i.e. sending IP-address is automatically rejected) - reverse DNS lookup does not work (i.e. symbolical name does not match IP address) - no or incorrect SPF-entry (sender policy framework) - other local filters may interpret mail as spam and reject.. and some more... sending and receiving emails can get quite complex... Best regards Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription (was HMC Mail domain)
At two places I worded at, one using Lotus Notes I never see Junk mail and some good mail unless I call the help desk and now here, currently MS-OE some mail deemed as junk never gets to me, they use a google service to weed out junk, and i get a quarantine email message telling me what emails was not delivered and an option to mark as not spam - Original Message - From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, January 27, 2017 12:25:37 PM Subject: Re: IBM-MAIN subscription (was HMC Mail domain) On Fri, 27 Jan 2017 17:01:58 +, Jesse 1 Robinson wrote: >My analysis: There is something missing in the confirmation email that causes >my company email system (Outlook) to reject the note as spam without >notification. And it didn't go into your Junk folder? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN subscription (was HMC Mail domain)
On Fri, 27 Jan 2017 17:01:58 +, Jesse 1 Robinson wrote: >My analysis: There is something missing in the confirmation email that causes >my company email system (Outlook) to reject the note as spam without >notification. And it didn't go into your Junk folder? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM-MAIN subscription (was HMC Mail domain)
I sent a request to Listserv Thursday afternoon: SUBSCRIBE IBM-MAIN Skipperoo Robinson I have not received any reply in my inbox. Today I sent the same request from my home email (ATT/Yahoo/Outlook) and got back an immediate response. My analysis: There is something missing in the confirmation email that causes my company email system (Outlook) to reject the note as spam without notification. My home email does not have the same filter. I cannot look at headers for the failing notes because--I never get them. My earlier explanation is from memory of a past conversation with an email tech who was able to look at a rejected note. I don't recall the exact missing tag(s). Note that I get all actual posts from IBM-Main. I also subscribed to ISPF-L and TSO-REXX 'normally' and get posts there as well. As I mentioned earlier, I have the same problem with RACF-L as with IBM-MAIN. My current subscription to IBM-MAIN was activated manually in early 2016. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Evans-Young, Darren Sent: Thursday, January 26, 2017 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: HMC Mail domain I just also verified this with my gmail account. Valid From: tag. Darren From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jesse 1 Robinson [jesse1.robin...@sce.com] Sent: Thursday, January 26, 2017 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HMC Mail domain This problem hits close to the heart of IBM-Main. I discovered a while back that a new email address could not successfully be registered from within the company network. This might be for a new person or for someone whose email address had changed. After considerable frustration, I learned that the IBM-Main confirmation email sent to a new registrant has a blank 'From' tag. Not structurally invalid, not unregistered. Empty. I assume that it had always been thus, but we hadn't tried to register a new email address in quite some time. Meanwhile our email nannies had implemented a new 'security' measure to reject any email that did not specify a From id. The sender is not verified AFAIK; there just has to be one. The argument is that this one action filters out a lot of true spam. So the confirmation email from IBM-Main looks like spam and is deleted without notice to the recipient. I take it that this is standard List server software behavior. I cannot imagine a business justification for it, but it requires that any new IBM-Main (or RACF-L) user ask for manual intervention from the List owner to add the user by hand. We are not a giant company, but we have several thousand email users. The idea of asking for an exemption for a literal handful of affected users is daunting, especially because the problem could be solved by a simple software change on the List server. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, January 26, 2017 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL: Re: HMC Mail domain In my humble opinion this is not a problem with HMC but network/email folks in the organisation. Any HMC name and domain has to be somehow "authorized" within company network. So, *some* effort has to be done, irrespectively of the name of HMC. If I could choose I would pay much more effort into customisation of HMC email content, to make it more clear and comfortable for users. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
