まぁ、こういう時代だから致し方ない、と言ってしまえばそれまで。
んなことは理解しているつもり。
同一メールを複数端末のMUAで読み出す手順、それもPCベンダFAQサイトの
一コンテンツとして公開するのに、POPでの手順を案内するかな、普通。
担当者曰く
「OSの操作手順ですから」
ですと。
はぁ、OSがthe internetの規定処理に準じているとでも思ってるのかしらん。
POP, SMTP, IMAPそれぞれ、どんなプロトコルでMTA - MUA間ではどのような処理が行われるべきなのか、を踏まえてほしい。今のISP側でPOP処理でのメールボックス サイズが大きくなっていかない理由だって、ちゃんとRFC 1939(POP version 3)に明記してあるのに。
いちPCベンダであれば、the internetがinfrastructureになり、PCがcommodity化した現在だからこそ、きちんと啓蒙すべき立場なのだから。その話を担当者にしたら
「それは社のポリシですか?」
....だったら、もうtechnical reviewerから俺を外してほしい。
そりゃ業務で作成しているのでしょうが、そもそもFAQコンテンツって、
ユーザのために作成し、サポートコストを低減する目的があるんじゃないの?!
>8. Scaling and Operational Considerations
>
> Since some of the optional features described above were added to the
> POP3 protocol, experience has accumulated in using them in large-
> scale commercial post office operations where most of the users are
> unrelated to each other. In these situations and others, users and
> vendors of POP3 clients have discovered that the combination of using
> the UIDL command and not issuing the DELE command can provide a weak
> version of the "maildrop as semi-permanent repository" functionality
> normally associated with IMAP. Of course the other capabilities of
> IMAP, such as polling an existing connection for newly arrived
> messages and supporting multiple folders on the server, are not
> present in POP3.
>
> When these facilities are used in this way by casual users, there has
> been a tendency for already-read messages to accumulate on the server
> without bound. This is clearly an undesirable behavior pattern from
> the standpoint of the server operator. This situation is aggravated
> by the fact that the limited capabilities of the POP3 do not permit
> efficient handling of maildrops which have hundreds or thousands of
> messages.
>
> Consequently, it is recommended that operators of large-scale multi-
> user servers, especially ones in which the user's only access to the
> maildrop is via POP3, consider such options as:
>
> * Imposing a per-user maildrop storage quota or the like.
>
> A disadvantage to this option is that accumulation of messages may
> result in the user's inability to receive new ones into the
> maildrop. Sites which choose this option should be sure to inform
> users of impending or current exhaustion of quota, perhaps by
> inserting an appropriate message into the user's maildrop.
>
> * Enforce a site policy regarding mail retention on the server.
>
> Sites are free to establish local policy regarding the storage and
> retention of messages on the server, both read and unread. For
> example, a site might delete unread messages from the server after
> 60 days and delete read messages after 7 days. Such message
> deletions are outside the scope of the POP3 protocol and are not
> considered a protocol violation.
んなことは理解しているつもり。
同一メールを複数端末のMUAで読み出す手順、それもPCベンダFAQサイトの
一コンテンツとして公開するのに、POPでの手順を案内するかな、普通。
担当者曰く
「OSの操作手順ですから」
ですと。
はぁ、OSがthe internetの規定処理に準じているとでも思ってるのかしらん。
POP, SMTP, IMAPそれぞれ、どんなプロトコルでMTA - MUA間ではどのような処理が行われるべきなのか、を踏まえてほしい。今のISP側でPOP処理でのメールボックス サイズが大きくなっていかない理由だって、ちゃんとRFC 1939(POP version 3)に明記してあるのに。
いちPCベンダであれば、the internetがinfrastructureになり、PCがcommodity化した現在だからこそ、きちんと啓蒙すべき立場なのだから。その話を担当者にしたら
「それは社のポリシですか?」
....だったら、もうtechnical reviewerから俺を外してほしい。
そりゃ業務で作成しているのでしょうが、そもそもFAQコンテンツって、
ユーザのために作成し、サポートコストを低減する目的があるんじゃないの?!
>8. Scaling and Operational Considerations
>
> Since some of the optional features described above were added to the
> POP3 protocol, experience has accumulated in using them in large-
> scale commercial post office operations where most of the users are
> unrelated to each other. In these situations and others, users and
> vendors of POP3 clients have discovered that the combination of using
> the UIDL command and not issuing the DELE command can provide a weak
> version of the "maildrop as semi-permanent repository" functionality
> normally associated with IMAP. Of course the other capabilities of
> IMAP, such as polling an existing connection for newly arrived
> messages and supporting multiple folders on the server, are not
> present in POP3.
>
> When these facilities are used in this way by casual users, there has
> been a tendency for already-read messages to accumulate on the server
> without bound. This is clearly an undesirable behavior pattern from
> the standpoint of the server operator. This situation is aggravated
> by the fact that the limited capabilities of the POP3 do not permit
> efficient handling of maildrops which have hundreds or thousands of
> messages.
>
> Consequently, it is recommended that operators of large-scale multi-
> user servers, especially ones in which the user's only access to the
> maildrop is via POP3, consider such options as:
>
> * Imposing a per-user maildrop storage quota or the like.
>
> A disadvantage to this option is that accumulation of messages may
> result in the user's inability to receive new ones into the
> maildrop. Sites which choose this option should be sure to inform
> users of impending or current exhaustion of quota, perhaps by
> inserting an appropriate message into the user's maildrop.
>
> * Enforce a site policy regarding mail retention on the server.
>
> Sites are free to establish local policy regarding the storage and
> retention of messages on the server, both read and unread. For
> example, a site might delete unread messages from the server after
> 60 days and delete read messages after 7 days. Such message
> deletions are outside the scope of the POP3 protocol and are not
> considered a protocol violation.