FWIW, the telnet mail interface typo fix should be: telnet bbs.winserver.com
-- HLS Hector Santos wrote: > I'm a MUA author of BOTH types and people forget that there are TWO > kinds here. We have: > > Console based Mail Reader/Writers Online Interface (Dialup/Telnet) > > telnet bbs.wisnerver.com > or > 305-248-7815 > > A Frontend Native GUI ONLINE Interface > > http://www.winserver.com/public/wcnavigator.wct > > A Frontend Web-based ONLINE Interface > > http://www.winserver.com (you have to log in) > > Two QWK, RFC 822/2822/5322 Offline Mail Reader/Writers: > > http://www.santronics.com/products/olx/index.php > http://www.santronics.com/products/sxpress/index.php > > Two Administrator Report Reader/Writer Online Interfaces > > http://www.santronics.com/products/pxpress/index.php > > A Outlook Exchange Component > > http://www.santronics.com/products/winserver/Exchange.php > > And very important > > NNTP (News) and POP3 (Email) Mail Servers to support ALL RFC > based Store and forward offline mail reader/writers. > > All MUAs, including are feed by the backend. It is the BACKEND that > feeds the children what it will eat (see). We can ALTER and DO > whatever we please to give whatever the ILLUSION we want the MUA to see. > > This issue is a BACKEND issue whether we want to deal with it at a: > > MSA Authenticated Submission (For Local or Remote User/Relay) > MDA Non-Authenticated Submission to LOCAL USER ONLY > > or at some DKIM integrated component. > > To assume that this is should be PUSHED first to MUAs is BAD > engineering and NAIVE. > > But that doesn't mean they don't have to look for it just in case an > 3rd party interface software (like an RFC-based mail/writer) whats to > make sure that all backends are correct. > > So as I said in an earlier post, technically, all parts need to deal > with this but more so the DKIM API because this is part of their > "Reason For Living" in the first place - mail integrity. > > Its like a Neighborhood Watch Program vs Real Cops. Everyone will > need to deal with it. But the BACKEND is the #1 place to deal with > this especially for systems that only have Online Interface devices > and/or Legacy Online or Offline mail readers who require (and don't > even think about it) that the backend "mommy" give them clean food to > eat - not poison, dirty food. > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html