Отговорите от пощенския списък отиват само до подателя, освен когато се използва отговор на всички

Работя върху базиран на PHP пощенски списък, използвайки PHPmailer.

В момента съм внедрил две опции за отговори на публикации в пощенския списък: отговор само на подател срещу отговор на списък. Това основно контролира кой адрес се вмъква в полето за отговор.

Искам да създам поведението, което потребителите ми познават от Mailman, ето пример:

SenderA публикува съобщение:

От: [email protected]

До: [email protected]

Пощенският списък го препраща до всички получатели, напр. тук за Получател A:

От: [email protected]

До: [email protected]

CC: [email protected]

Сега RecipientA отговаря на публикацията и отговорът изглежда така:

От: [email protected]

До: [email protected]

Другата опция, която RecipientA има, е да публикува отговора на цялото писмо, като избере отговор на всички в мейл клиента, който изглежда така в отговора:

От: [email protected]

До: [email protected]

CC: [email protected]

Когато реша да задам адреса на пощенския списък в полето CC за всички препратени имейли:

  • Това означава ли, че пощата се връща в пощенския списък 100 пъти, когато изпратя пощата до 100 абонати (-› извличането, проверката и премахването на тези дублиращи се пощи ще струва много работа)

  • Мога ли да включа определен хедър, така че пощата до пощенския списък с CC да не се изпраща 100 пъти? Как мога да кажа на мейл сървъра(ите) да не прави това?

Or:

  • Има ли алтернативен начин да се позволи на потребителите да решат да отговорят на подателя или на целия списък?

list php phpmailer mailman mailing
person hbit    schedule 14.12.2010    source източник
comment
Доколкото знам, в phpmailer можете да зададете отговор до ( askapache.com/php/ ): По времето, когато е написан този урок, ето списък с функции, налични в момента: Може да изпраща имейли с множество TO, CC, BCC и REPLY-TO   -  person Catalin    schedule 14.12.2010
comment
Точно така, това вече правя. Но няма нищо като Reply-CC, което би било идеалното съвпадение.   -  person hbit    schedule 14.12.2010
comment
Бихте могли да симулирате от скрипта, който изпраща имейла...добавете към отговор-само на адресите cc...направете някакъв вид селектор, който да пита потребителя на кого трябва да може получателят да отговори...в крайна сметка добавете списък с квадратчета за отметка с всички адреси, за да може да провери кого да добави в отговора...   -  person Catalin    schedule 15.12.2010
comment
Това не решава проблема - нямам влияние върху начина, по който потребителите виждат имейлите -› могат да използват всякакви видове имейл клиенти. Единственият начин, по който виждам, че потребителят има шанс да направи този избор, е като избере отговор срещу отговор -to-all в неговия имейл клиент. И това води до проблема, че акаунтът в пощенския списък получава спам със собствените си имейли.   -  person hbit    schedule 15.12.2010
comment
Какво става, ако предоставя поле за заглавка Message-ID? От Wikipedia: Message-ID: също автоматично генерирано поле; използва се за предотвратяване на многократна доставка и за справка в In-Reply-To [...] Когато предоставя Message-ID в моята програма гарантира ли се, че пощенският сървър няма да създаде нов? Това пречи ли на целевия имейл сървър да работи 1000 пъти с едно и също съобщение?   -  person hbit    schedule 16.12.2010

Отговори (1)


arrow_upward
0
arrow_downward

Разбрах го - повечето имейл клиенти ще третират отговарянето на имейли от пощенския списък по желание, когато са изпълнени следните условия за изходящите имейли от пощенския списък:

  • Имейлите идват със стандартните заглавки на пощенския списък съгласно RFC 2369, определено имате нужда от Списък-публикуване с нещо като <mailto:[email protected]>
  • За отговори само до подателя се нуждаете или от правилно зададено заглавно поле От (трябва да е имейлът на подателя, [email protected] в примера) или заглавно поле Отговор до в случай че не можете да промените полето От

Това е малко по-различно от подхода на Mailman, но работи много добре и можете да сте сигурни, че вашият сървър не трябва да се справя с нежелани дубликати

person hbit    schedule 29.08.2011