Community Discussions and Support
Who gets the reply?

[quote user="David Obdrzalek"]But what if they are local in respect to the mailserver, not Pegasus? Pegasus cannot know about all users, then. I foggily remember it might have been so when we used the Novell mailserver years ago - writing to users in the department by short name and to the outside world by internet addresses containing @. [/quote]

You are right, in such case Pmail is not able to know about all local users. But if this is true, the user (or admin) should get the opportunity to decide whether he want to use local user names or not. To avoid the permanent error messages from Mercury (about 10 to 15 postmaster notifications per day @ 10 users) I would immediately disable the usage of local user names for internal communication, especially when auto-completing is activated - that means normally no more typing effort.

Joerg

<p>[quote user="David Obdrzalek"]But what if they are local in respect to the mailserver, not Pegasus? Pegasus cannot know about all users, then. I foggily remember it might have been so when we used the Novell mailserver years ago - writing to users in the department by short name and to the outside world by internet addresses containing @. [/quote]</p><p>You are right, in such case Pmail is not able to know about all local users. But if this is true, the user (or admin) should get the opportunity to decide whether he want to use local user names or not. To avoid the permanent error messages from Mercury (about 10 to 15 postmaster notifications per day @ 10 users) I would immediately disable the usage of local user names for internal communication, especially when auto-completing is activated - that means normally no more typing effort.</p><p>Joerg </p>

Basically the question was hidden in a suggestion but belongs here. I apologize for the crossposting.

When the sender is of the form, e.g.

?iso-8859-1?Q?G=F6r[...]<email@address>

often several replies are sent.

1st Question: Does Pegasus always send the reply to email@address, the term in brackets <>.?

Often the are additional addresses derived from the term before the brackets, generating "Recipient address rejected: User unknown".

 2nd Question: When does Pegasus send a reply to anything before the brackets? When there is
a) a comma,
b) a code with more than one byte
c) some other reason

 Oskar

 

Oskar

&lt;p&gt;Basically the question was hidden in a suggestion but belongs here. I apologize for the crossposting. &lt;/p&gt;&lt;p&gt;When the sender is of the form, e.g. &lt;/p&gt;&lt;div class=&quot;ForumPostBodyArea&quot;&gt;&lt;div id=&quot;ctl00_ctl01_bcr_SinglePostView___PostViewWrapper&quot; class=&quot;ForumPostContentText&quot;&gt;&lt;p&gt;?iso-8859-1?Q?G=F6r[...]&amp;lt;email@address&amp;gt;&lt;/p&gt;&lt;p&gt;often several replies are sent.&lt;/p&gt;&lt;p&gt;1st Question: Does Pegasus always send the reply to email@address, the term in brackets &amp;lt;&amp;gt;.?&lt;/p&gt;&lt;p&gt;Often the are additional addresses derived from the term before the brackets, generating &quot;Recipient address rejected: User unknown&quot;.&lt;/p&gt;&lt;p&gt;&amp;nbsp;2nd Question: When does Pegasus send a reply to anything before the brackets? When there is a) a comma, b) a code with more than one byte c) some other reason &lt;/p&gt;&lt;p&gt;&amp;nbsp;Oskar&lt;/p&gt;&lt;/div&gt; &lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Oskar &lt;/p&gt;

[quote user="vdhagen"] 2nd Question: When does Pegasus send a reply to anything before the brackets?[/quote]

You tell us: I've never seen this before and I'm sure there would by lots of complaints if this would happen more frequently. IOW: If you provide a sample we will be able to look into this (sounds more like a non-RFC conformant header than anything else unless there's a new encoding scheme involved) ...

&lt;p&gt;[quote user=&quot;vdhagen&quot;] 2nd Question: When does Pegasus send a reply to anything before the brackets?[/quote]&lt;/p&gt;&lt;p&gt;You tell us: I&#039;ve never seen this before and I&#039;m sure there would by lots of complaints if this would happen more frequently. IOW: If you provide a sample we will be able to look into this (sounds more like a non-RFC conformant header than anything else unless there&#039;s a new encoding scheme involved) ...&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

I guess the sender uses Outlook. In "raw" the mail contains:

"Return-Path: <firstname.loestname@...>
From: =?iso-8859-1?Q?L=F6stname=2C_Firstname?=
        <firstname.loestname@...>"

where "lastname" is supposed to contain an o-umlaut.

I can't choose the  "Return-Path" in Pegasus for a reply. When I choose the "From" field I always get a "Mail Delivery Failure":

"Delivery has failed on the enclosed message for the following
reasons reported either by the mail delivery system on the mail
relay host or by the local TCP/IP transport module:

   550 5.1.1 <L  stname>: Recipient address rejected: User unknown in local
   recipient table"

This happens regularly with every lastname, firstname <address> where the lastname contains an umlaut.

Apparently I don't have to resend the mail because Pegasus does send a mail to the address in brackets.

Oskar

 

&lt;p&gt;I guess the sender uses Outlook. In &quot;raw&quot; the mail contains:&lt;/p&gt;&lt;p&gt;&quot;Return-Path: &amp;lt;firstname.loestname@...&amp;gt; From: =?iso-8859-1?Q?L=F6stname=2C_Firstname?= &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;lt;firstname.loestname@...&amp;gt;&quot;&lt;/p&gt;&lt;p&gt;where &quot;lastname&quot; is supposed to contain an o-umlaut.&lt;/p&gt;&lt;p&gt;I can&#039;t choose the&amp;nbsp; &quot;Return-Path&quot; in Pegasus for a reply. When I choose the &quot;From&quot; field I always get a &quot;Mail Delivery Failure&quot;:&lt;/p&gt;&lt;p&gt;&quot;Delivery has failed on the enclosed message for the following reasons reported either by the mail delivery system on the mail relay host or by the local TCP/IP transport module: &amp;nbsp;&amp;nbsp; 550 5.1.1 &amp;lt;L&amp;nbsp; stname&amp;gt;: Recipient address rejected: User unknown in local &amp;nbsp;&amp;nbsp; recipient table&quot;&lt;/p&gt;&lt;p&gt;This happens regularly with every lastname, firstname &amp;lt;address&amp;gt; where the lastname contains an umlaut.&lt;/p&gt;&lt;p&gt;Apparently I don&#039;t have to resend the mail because Pegasus does send a mail to the address in brackets.&lt;/p&gt;&lt;p&gt;Oskar &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[Contents removed due to accidental double post, sorry, can't delete it anymore]

&lt;p&gt;&lt;font color=&quot;#cccccc&quot;&gt;[Contents removed due to accidental double post, sorry, can&#039;t delete it anymore]&lt;/font&gt;&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="vdhagen"]I guess the sender uses Outlook.[/quote]

I don't think so since we would have already had lots of error reports otherwise.

[quote user="vdhagen"]From: =?iso-8859-1?Q?L=F6stname=2C_Firstname?= <firstname.loestname@...>[/quote]

Which is in fact broken and not related to the umlaut in any kind: The reason for the failure is missing double quotes around the real name so it would look like this, e.g.:

From: =?iso-8859-1?Q?=22L=F6stname=2C_Firstname=22?= <firstname.loestname@...>.

The sender's email application might be indicated by the X-MAILER header, BTW, MSO usually inserts an X-MimeOLE header AFAIK. For reference see RFC 5322 in sections 3.2.3 through 3.2.5, relevant parts (reformatted for readability by non-geeks; atext = text in so-called "atoms" which are single words containing US-ASCII characters excluding the following ones):

Special characters that do not appear in atext

specials = ( ) < > [ ] : ; @ \ , . DQUOTE

Strings of characters that include characters other than those
allowed in atoms can be represented in a quoted string format, where

the characters are surrounded by quote (DQUOTE, ASCII value 34) characters.

The fact that the sender application fails on this might be related to the umlaut encoding in so far as the encoded variant actually is an atom only containing US-ASCII characters, but only after encoding, so I'm not sure whether Pegasus Mail needs to take this into account itself ...

[quote user=&quot;vdhagen&quot;]I guess the sender uses Outlook.[/quote] &lt;p&gt;I don&#039;t think so since we would have already had &lt;em&gt;lots of error reports&lt;/em&gt; otherwise.&lt;/p&gt; &lt;p&gt;[quote user=&quot;vdhagen&quot;]From: =?iso-8859-1?Q?L=F6stname=2C_Firstname?= &amp;lt;firstname.loestname@...&amp;gt;[/quote]&lt;/p&gt; &lt;p&gt;Which is in fact broken and not related to the umlaut in any kind: The reason for the failure is missing double quotes around the real name so it would look like this, e.g.:&lt;/p&gt; &lt;p&gt;From: =?iso-8859-1?Q?&lt;strong&gt;&lt;font color=&quot;#ff0000&quot;&gt;=22&lt;/font&gt;&lt;/strong&gt;L=F6stname=2C_Firstname&lt;strong&gt;&lt;font color=&quot;#ff0000&quot;&gt;=22&lt;/font&gt;&lt;/strong&gt;?= &amp;lt;firstname.loestname@...&amp;gt;.&lt;/p&gt; &lt;p&gt;The sender&#039;s email application might be indicated by the &lt;em&gt;X-MAILER&lt;/em&gt; header, BTW, MSO usually inserts&amp;nbsp;an &lt;em&gt;X-MimeOLE&lt;/em&gt; header AFAIK. For reference see &lt;a href=&quot;http://www.rfc-editor.org/rfc/rfc5322.txt&quot; mce_href=&quot;http://www.rfc-editor.org/rfc/rfc5322.txt&quot; target=&quot;_blank&quot;&gt;RFC 5322&lt;/a&gt; in sections 3.2.3 through 3.2.5, relevant parts (reformatted for readability by non-geeks; atext = text in so-called &quot;atoms&quot; which are single words containing US-ASCII characters excluding the following ones): &lt;/p&gt; &lt;blockquote&gt; &lt;p&gt;Special characters that do not appear in atext&lt;/p&gt; &lt;p&gt;specials = ( ) &amp;lt; &amp;gt; [ ] : ; @ \ , . DQUOTE &lt;/p&gt; Strings of characters that include &lt;strong&gt;characters other than those allowed in atoms can be represented in a quoted string format&lt;/strong&gt;, where &lt;p&gt;the characters are surrounded by quote (DQUOTE, ASCII value 34) characters.&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;The fact that the sender application fails on this might be related to the umlaut encoding in so far as the encoded variant actually &lt;em&gt;is an atom&lt;/em&gt; only containing US-ASCII characters, but only &lt;em&gt;after&lt;/em&gt; encoding, so I&#039;m not sure whether Pegasus Mail needs to take this into account itself ...&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="idw"]

[quote user="vdhagen"]From: =?iso-8859-1?Q?L=F6stname=2C_Firstname?= <firstname.loestname@...>[/quote]

Which is in fact broken and not related to the umlaut in any kind: The reason for the failure is missing double quotes around the real name so it would look like this, e.g.:

From: =?iso-8859-1?Q?=22L=F6stname=2C_Firstname=22?= <firstname.loestname@...>.

[/quote]

I checked the mailing lists of our department:

  • All names without umlaut have entries like: "lastname, firstname" <email-address>
  • All name with an umlaut start with =?iso-8859-1 and do not contain the =22.

Supposedly Outlook and Thunderbird are satisfied with this format.

 

[quote user=&quot;idw&quot;]&lt;p&gt;[quote user=&quot;vdhagen&quot;]From: =?iso-8859-1?Q?L=F6stname=2C_Firstname?= &amp;lt;firstname.loestname@...&amp;gt;[/quote]&lt;/p&gt; &lt;p&gt;Which is in fact broken and not related to the umlaut in any kind: The reason for the failure is missing double quotes around the real name so it would look like this, e.g.:&lt;/p&gt; &lt;p&gt;From: =?iso-8859-1?Q?&lt;b&gt;&lt;font color=&quot;#ff0000&quot;&gt;=22&lt;/font&gt;&lt;/b&gt;L=F6stname=2C_Firstname&lt;b&gt;&lt;font color=&quot;#ff0000&quot;&gt;=22&lt;/font&gt;&lt;/b&gt;?= &amp;lt;firstname.loestname@...&amp;gt;.&lt;/p&gt;[/quote]&lt;p&gt;I checked the mailing lists of our department: &lt;/p&gt; &lt;ul&gt;&lt;li&gt;All names without umlaut have entries like: &quot;lastname, firstname&quot; &amp;lt;email-address&amp;gt;&lt;/li&gt;&lt;li&gt;All name with an umlaut start with =?iso-8859-1 and do not contain the =22.&lt;/li&gt;&lt;/ul&gt; Supposedly Outlook and Thunderbird are satisfied with this format.&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Hi,

 Maybe a bit late but I confirm that this is still an issue today. User names containing special characters, for instance a German umlaut, arrive iso-8859-1 encoded but unquoted from MS mailers, and a reply to them fails. Wouldn't Pegasus be compliant if it was automatically quoting the decoded name (if it is unquoted)?

&lt;p&gt;Hi,&lt;/p&gt;&lt;p&gt;&amp;nbsp;Maybe a bit late but I confirm that this is still an issue today. User names containing special characters, for instance a German umlaut, arrive iso-8859-1 encoded but &lt;b&gt;unquoted&lt;/b&gt; from MS mailers, and a reply to them fails. Wouldn&#039;t Pegasus be compliant if it was automatically quoting the decoded name (if it is unquoted)? &lt;/p&gt;

Hi guys,

I would also like to take up this old thread to bring the problem on the table again, allthough it is explained different times - but it is still annoying us. Our users very often experience problems during Pmail REPLIES with wrong formatted sender's addresses, especially in format:

last name, first name <firstname.lastname@domain.com>

As already sufficiently explained in this forum RFC defines the Comma as a separator for a list of different e-mail addresses. And in case the Real User Name is being transmitted additionally in front of the e-mail address in the FROM field, the e-mail address should be enclosed in brackets < >. Further, in case any special characters are in use within the Real User Name, this name should be enclosed in quotation marks. This is clear so far.

Nevertheless many other e-mail clients seems to ignore the RFC standard and do not enclose the Real User Name in quotation marks. That's why Pmail recognizes the Comma as an address separator and tries to send the mail to both:

1. last name

2. first name <firstname.lastname@domain.com>

The first (incomplete) address generates an error message from Mercury while the second address is valid and is being transmitted. Insofar it works and the mail is getting sent to the recipient but the repeatedly appearing error messages are annoying all.

Anyway. We are knowing that Pail is working correctly in case all participents are supporting the RFC standard. But they don't. And this is no secret. Why Pmail has no better recognition ability for wrong or incomplete e-mail addresses? In the meantime different of my users are prefering to work with other mail clients (e.g. Thunderbird). Those clients have no problems with the wrong formatted addresses. They check the validity of e-mail addresses in the FROM: field and sort them automatically out. I would wish such an ability for Pmail, too.

Cheers

Joerg

&lt;p&gt;Hi guys,&lt;/p&gt;&lt;p&gt;I would also like to take up this old thread to bring the problem on the table again, allthough it is explained different times - but it is still annoying us. Our users very often experience problems during Pmail REPLIES with wrong formatted sender&#039;s addresses, especially in format:&lt;/p&gt;&lt;p&gt;last name, first name &amp;lt;firstname.lastname@domain.com&amp;gt;&lt;/p&gt;&lt;p&gt;As already sufficiently explained in this forum RFC defines the &lt;b&gt;Comma&lt;/b&gt; as a separator for a list of different e-mail addresses. And in case the Real User Name is being transmitted additionally in front of the e-mail address in the FROM field, the e-mail address should be enclosed in brackets &amp;lt; &amp;gt;. Further, in case any special characters are in use within the Real User Name, this name should be enclosed in quotation marks. This is clear so far.&lt;/p&gt;&lt;p&gt;Nevertheless many other e-mail clients seems to ignore the RFC standard and do not enclose the Real User Name in quotation marks. That&#039;s why Pmail recognizes the Comma as an address separator and tries to send the mail to both:&lt;/p&gt;&lt;p&gt;1. last name &lt;/p&gt;&lt;p&gt;2. first name &amp;lt;firstname.lastname@domain.com&amp;gt;&lt;/p&gt;&lt;p&gt;The first (incomplete) address generates an error message from Mercury while the second address is valid and is being transmitted. Insofar it works and the mail is getting sent to the recipient but the repeatedly appearing error messages are annoying all. &lt;/p&gt;&lt;p&gt;Anyway. We are knowing that Pail is working correctly in case all participents are supporting the RFC standard. But they don&#039;t. And this is no secret. Why Pmail has no better recognition ability for wrong or incomplete e-mail addresses? In the meantime different of my users are prefering to work with other mail clients (e.g. Thunderbird). Those clients have no problems with the wrong formatted addresses. They check the validity of e-mail addresses in the FROM: field and sort them automatically out. I would wish such an ability for Pmail, too.&lt;/p&gt;&lt;p&gt;Cheers&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

This is a problem here as well.  One of our outside salespeople uses an iPhone and an icloud.com email account for business communications.  He forwards messages to office support staff who then attempt to reply-all but often experience failure as Joerg described.  I don't work with these messages first hand but I see the failed delivery notices.  I don't whether the problem originates with the original sender or in the forwarding by the iPhone but AFAIK the iPhone handles replies just fine.

This is a problem here as well.&amp;nbsp; One of our outside salespeople uses an iPhone and an icloud.com email account for business communications.&amp;nbsp; He forwards messages to office support staff who then attempt to reply-all but often experience failure as Joerg described.&amp;nbsp; I don&#039;t work with these messages first hand but I see the failed delivery notices.&amp;nbsp; I don&#039;t whether the problem originates with the original sender or in the forwarding by the iPhone but AFAIK the iPhone handles replies just fine.

My idea of explanation: Pegasus reports invalid addresses while the others do not. Then, if email application X finds lastname, firstname <whoever@wherever.any> as the address, it does not care, it sends both and drops the smtp server error message about lastname being invalid address.

Second idea: Application Y parses the To: address, finds out there are two addresses separated by comma (following the RFC). Then it drops the first part (lastname) for not being valid address and sends only to the second one (firstname <whoever@wherever.any>). But Pegasus does not do it as Pegasus also can deliver to "local" addresses which do not have the @... part and relies on the mailserver (Mercury should be) to do so. But other mailservers do not do that and reject it back as invalid address.

(sorry, neither of these two can help you, it is just my explanation about different behaviour of Pegasus and other clients)

&lt;p&gt;My idea of explanation: Pegasus reports invalid addresses while the others do not. Then, if email application X finds &lt;i&gt;lastname, firstname &amp;lt;whoever@wherever.any&amp;gt;&lt;/i&gt; as the address, it does not care, it sends both and drops the smtp server error message about &lt;i&gt;lastname&lt;/i&gt; being invalid address.&lt;/p&gt;&lt;p&gt;Second idea: Application Y parses the To: address, finds out there are two addresses separated by comma (following the RFC). Then it drops the first part (&lt;i&gt;lastname&lt;/i&gt;) for not being valid address and sends only to the second one (&lt;i&gt;firstname &amp;lt;whoever@wherever.any&amp;gt;&lt;/i&gt;). But Pegasus does not do it as Pegasus also can deliver to &quot;local&quot; addresses which do not have the @... part and relies on the mailserver (Mercury should be) to do so. But other mailservers do not do that and reject it back as invalid address. &lt;/p&gt;&lt;p&gt;(sorry, neither of these two can help you, it is just my explanation about different behaviour of Pegasus and other clients) &lt;/p&gt;

[quote user="David Obdrzalek"] ... if email application X finds lastname, firstname <whoever@wherever.any> as the address, it does not care, it sends both and drops the smtp server error message about lastname being invalid address.[/quote]

I don't think so because only one valid address appears in the To: address field when pressing REPLY. (e.g. in Thunderbird)

[quote user="David Obdrzalek"] Second idea: Application Y parses the To: address, finds out there are two addresses separated by comma (following the RFC). Then it drops the first part (lastname) for not being valid address and sends only to the second one (firstname <whoever@wherever.any>). But Pegasus does not do it as Pegasus also can deliver to "local" addresses which do not have the @... part and relies on the mailserver (Mercury should be) to do so. But other mailservers do not do that and reject it back as invalid address.[/quote]

That's right, I think. But, 1st: it's not possible to create long local user names with Mercury/Pmail. This would be the first filter where Pmail could sort out invalid names. And 2nd: Pmail should know about all registered local user (see Pmail > Menu > Adresses > User administration) and could check whether a local user is valid or not.

If desired, Pmail could check the validity in advance and not only by "try and error"


&lt;p&gt;[quote user=&quot;David Obdrzalek&quot;] ... if email application X finds &lt;i&gt;lastname, firstname &amp;lt;whoever@wherever.any&amp;gt;&lt;/i&gt; as the address, it does not care, it sends both and drops the smtp server error message about &lt;i&gt;lastname&lt;/i&gt; being invalid address.[/quote]&lt;/p&gt;&lt;p&gt;I don&#039;t think so because only one valid address appears in the To: address field when pressing REPLY. (e.g. in Thunderbird) &lt;/p&gt;&lt;p&gt;[quote user=&quot;David Obdrzalek&quot;] Second idea: Application Y parses the To: address, finds out there are two addresses separated by comma (following the RFC). Then it drops the first part (&lt;i&gt;lastname&lt;/i&gt;) for not being valid address and sends only to the second one (&lt;i&gt;firstname &amp;lt;whoever@wherever.any&amp;gt;&lt;/i&gt;). But Pegasus does not do it as Pegasus also can deliver to &quot;local&quot; addresses which do not have the @... part and relies on the mailserver (Mercury should be) to do so. But other mailservers do not do that and reject it back as invalid address.[/quote]&lt;/p&gt;&lt;p&gt;That&#039;s right, I think. But, 1st: it&#039;s not possible to create long local user names with Mercury/Pmail. This would be the first filter where Pmail could sort out invalid names. And 2nd: Pmail should know about all registered local user (see Pmail &amp;gt; Menu &amp;gt; Adresses &amp;gt; User administration) and could check whether a local user is valid or not.&lt;/p&gt;&lt;p&gt;If desired, Pmail could check the validity in advance and not only by &quot;try and error&quot; &lt;/p&gt;

[quote user="Joerg"]

That's right, I think. But, 1st: it's not possible to create long local user names with Mercury/Pmail. This would be the first filter where Pmail could sort out invalid names.

[/quote]

I mean Pegasus might consider it as two addresses, first one being local (and short), second one being internet addres.

[quote user="Joerg"]

And 2nd: Pmail should know about all registered local user (see Pmail > Menu > Adresses > User administration) and could check whether a local user is valid or not.

If desired, Pmail could check the validity in advance and not only by "try and error"


[/quote]

But what if they are local in respect to the mailserver, not Pegasus? Pegasus cannot know about all users, then. I foggily remember it might have been so when we used the Novell mailserver years ago - writing to users in the department by short name and to the outside world by internet addresses containing @.

 

&lt;p&gt;[quote user=&quot;Joerg&quot;]&lt;/p&gt;&lt;p&gt;That&#039;s right, I think. But, 1st: it&#039;s not possible to create long local user names with Mercury/Pmail. This would be the first filter where Pmail could sort out invalid names. &lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;I mean Pegasus might consider it as two addresses, first one being local (and short), second one being internet addres. &lt;/p&gt;&lt;p&gt;[quote user=&quot;Joerg&quot;]&lt;/p&gt;&lt;p&gt;And 2nd: Pmail should know about all registered local user (see Pmail &amp;gt; Menu &amp;gt; Adresses &amp;gt; User administration) and could check whether a local user is valid or not.&lt;/p&gt;&lt;p&gt;If desired, Pmail could check the validity in advance and not only by &quot;try and error&quot; &lt;/p&gt;&lt;p&gt; [/quote]&lt;/p&gt;&lt;p&gt;But what if they are local in respect to the mailserver, not Pegasus? Pegasus cannot know about all users, then. I foggily remember it might have been so when we used the Novell mailserver years ago - writing to users in the department by short name and to the outside world by internet addresses containing @. &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft