How about FROM: <[email protected]>, or FROM: <[email protected]>?
On Sat, Jan 28, 2017 at 8:04 PM, Jesse 1 Robinson <[email protected]> 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 > [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 -- 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 [email protected] with the message: INFO IBM-MAIN
