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