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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Boyes Sent: Saturday, January 28, 2017 5:35 PM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN
