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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Boyes Sent: Sunday, February 12, 2017 10:55 AM To: [email protected] 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. <insert appropriate designation of spammer jerks here> (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 [email protected] with the message: INFO IBM-MAIN
