fixes in assp 2.5.6 build 17151

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

fixes in assp 2.5.6 build 17151

Thomas Eckardt/eck
Hi all,

fixed in assp 2.5.6 build 17151:


changed:

AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options

'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'
 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".
 If not disabled, both header lines will be added for all emails to all collected .eml files.


Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <[hidden email]> wrote:
Hi all,

fixed in assp 2.5.6 build 17151:


changed:

AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options

'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'
 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".
 If not disabled, both header lines will be added for all emails to all collected .eml files.


Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

Thomas Eckardt/eck
>Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

No - it works around your bad mail server config.
Your MTA should send the mail as it was created (except local recipients) - or a single mail to each recipient - not sending it to each external recipient (also bcc) in a single mail.

>1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?


yes

>2) Might you be able to change functionality so that we have the option to :
>   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 

What else is this function doing?

   b) remove these lines from files that are resent (for the same reason)


This was already done.

>My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

done


Thomas




Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        31.05.2017 23:56
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <Thomas.Eckardt@...> wrote:
Hi all,

fixed in assp 2.5.6 build 17151:



changed:


AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options


'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'

 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".

 If not disabled, both header lines will be added for all emails to all collected .eml files.



Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
Shucks, I thought I had finally found a bug that wasn't due to my idiocy (or the idiocy of other software that I'm using)

If you don't mind,more questions / comments:

1) In this new version, did the code change to now insure that the X-ASSP-intendedfor lines are now not in the MTA stream no matter how stupid the sending MTA is?  I ask because I definitely wasn't seeing that behavior before, the intended for line was in the header that the MTA delivers to the inbox.

2) I think the problem is that if using a smarthost with Exchange, it routes single messages to the smarthost as one, regardless of the domain(s) of the recipients.  Have you seen this before?  My gut says that ASSP has never considered this before and we've probably  been giving away bcc info for years.



On Thu, Jun 1, 2017 at 1:10 AM, Thomas Eckardt <[hidden email]> wrote:
>Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

No - it works around your bad mail server config.
Your MTA should send the mail as it was created (except local recipients) - or a single mail to each recipient - not sending it to each external recipient (also bcc) in a single mail.

>1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?


yes

>2) Might you be able to change functionality so that we have the option to :
>   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 

What else is this function doing?

   b) remove these lines from files that are resent (for the same reason)


This was already done.

>My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

done


Thomas




Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        31.05.2017 23:56
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <[hidden email]> wrote:
Hi all,

fixed in assp 2.5.6 build 17151:



changed:


AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options


'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'

 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".

 If not disabled, both header lines will be added for all emails to all collected .eml files.



Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
With this new version, the gui says "both header lines will be added for all emails to all collected .eml files"   The issue I'm seeing is that if AddIntendedForHeader is not disabled, not only does it add it to the eml file as expected, but it's also adding it to the stream that the MTA sees.  I see the value of having this in the eml files in the mailstore, but putting the intended for header into the header that the recipient can see when the message was BCC'ed is presenting a big problem.  

We smart host relay from Exchange through ASSP.  Exchange and lots of other mail clients when setup with a smarthost send a single message to the smarthost for multiple recipients.  If some are bcc'ed, that's still a single message.  It's not unusual for our staff to send a message to 50 bcc addresses.  They leave the outgoing MTA just fine, but because they went through the ASSP relay port (or were sent directly through the standard port for pop/smtp clients), all of the recipients show x-assp-intended-for lines, negating the purpose of bcc.

If I disable AddIntendedForHeader, it doesn't show, but then it's not recorded in the eml file either, which is better than revealing bcc recipients, but sub-optimal.

Even if I could change the behavior of the way that Exchange sends to a smarthost (which I can't), we can't control how other MTA's send to us.  If someone outside sends a single message with one to and one bcc to us, the recipient can see the bcc recipient in the header, which betrays the trust that the sender had in us - (and maybe violates RFC's ???)

SO - the real question is if there's a possibility to essentially remove the AddIntendedForHeader from the gui and ALWAYS add the intended for and envelope from to the eml file on the ASSP server but NOT send these lines to the receiving MTA under any circumstance.

And if this is possible, what downside is there to not having these lines in the email header except in the corpus.  Would spam reporting be impacted?

Line 44625 has    if ($AddIntendedForHeader)  and then it prints the intended for header lines.  It doesn't seem to check what the value of AddIntendedForHeader is, so if it's not disabled, it'll print it regardless of inbound or outbound.  I don't know if this is an oversight or if I'm just not understanding correctly.



On Thu, Jun 1, 2017 at 8:26 PM, K Post <[hidden email]> wrote:
Shucks, I thought I had finally found a bug that wasn't due to my idiocy (or the idiocy of other software that I'm using)

If you don't mind,more questions / comments:

1) In this new version, did the code change to now insure that the X-ASSP-intendedfor lines are now not in the MTA stream no matter how stupid the sending MTA is?  I ask because I definitely wasn't seeing that behavior before, the intended for line was in the header that the MTA delivers to the inbox.

2) I think the problem is that if using a smarthost with Exchange, it routes single messages to the smarthost as one, regardless of the domain(s) of the recipients.  Have you seen this before?  My gut says that ASSP has never considered this before and we've probably  been giving away bcc info for years.



On Thu, Jun 1, 2017 at 1:10 AM, Thomas Eckardt <[hidden email]> wrote:
>Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

No - it works around your bad mail server config.
Your MTA should send the mail as it was created (except local recipients) - or a single mail to each recipient - not sending it to each external recipient (also bcc) in a single mail.

>1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?


yes

>2) Might you be able to change functionality so that we have the option to :
>   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 

What else is this function doing?

   b) remove these lines from files that are resent (for the same reason)


This was already done.

>My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

done


Thomas




Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        31.05.2017 23:56
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <[hidden email]> wrote:
Hi all,

fixed in assp 2.5.6 build 17151:



changed:


AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options


'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'

 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".

 If not disabled, both header lines will be added for all emails to all collected .eml files.



Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
I played some more, if comment out 44625 and the closing } several lines down, ASSP seems to do what I want - add the intended for line to the eml file ALWAYS but never into the MTA stream.  is there a reason we wouldn't always want the system to work this way?

On Sat, Jun 3, 2017 at 8:43 PM, K Post <[hidden email]> wrote:
With this new version, the gui says "both header lines will be added for all emails to all collected .eml files"   The issue I'm seeing is that if AddIntendedForHeader is not disabled, not only does it add it to the eml file as expected, but it's also adding it to the stream that the MTA sees.  I see the value of having this in the eml files in the mailstore, but putting the intended for header into the header that the recipient can see when the message was BCC'ed is presenting a big problem.  

We smart host relay from Exchange through ASSP.  Exchange and lots of other mail clients when setup with a smarthost send a single message to the smarthost for multiple recipients.  If some are bcc'ed, that's still a single message.  It's not unusual for our staff to send a message to 50 bcc addresses.  They leave the outgoing MTA just fine, but because they went through the ASSP relay port (or were sent directly through the standard port for pop/smtp clients), all of the recipients show x-assp-intended-for lines, negating the purpose of bcc.

If I disable AddIntendedForHeader, it doesn't show, but then it's not recorded in the eml file either, which is better than revealing bcc recipients, but sub-optimal.

Even if I could change the behavior of the way that Exchange sends to a smarthost (which I can't), we can't control how other MTA's send to us.  If someone outside sends a single message with one to and one bcc to us, the recipient can see the bcc recipient in the header, which betrays the trust that the sender had in us - (and maybe violates RFC's ???)

SO - the real question is if there's a possibility to essentially remove the AddIntendedForHeader from the gui and ALWAYS add the intended for and envelope from to the eml file on the ASSP server but NOT send these lines to the receiving MTA under any circumstance.

And if this is possible, what downside is there to not having these lines in the email header except in the corpus.  Would spam reporting be impacted?

Line 44625 has    if ($AddIntendedForHeader)  and then it prints the intended for header lines.  It doesn't seem to check what the value of AddIntendedForHeader is, so if it's not disabled, it'll print it regardless of inbound or outbound.  I don't know if this is an oversight or if I'm just not understanding correctly.



On Thu, Jun 1, 2017 at 8:26 PM, K Post <[hidden email]> wrote:
Shucks, I thought I had finally found a bug that wasn't due to my idiocy (or the idiocy of other software that I'm using)

If you don't mind,more questions / comments:

1) In this new version, did the code change to now insure that the X-ASSP-intendedfor lines are now not in the MTA stream no matter how stupid the sending MTA is?  I ask because I definitely wasn't seeing that behavior before, the intended for line was in the header that the MTA delivers to the inbox.

2) I think the problem is that if using a smarthost with Exchange, it routes single messages to the smarthost as one, regardless of the domain(s) of the recipients.  Have you seen this before?  My gut says that ASSP has never considered this before and we've probably  been giving away bcc info for years.



On Thu, Jun 1, 2017 at 1:10 AM, Thomas Eckardt <[hidden email]> wrote:
>Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

No - it works around your bad mail server config.
Your MTA should send the mail as it was created (except local recipients) - or a single mail to each recipient - not sending it to each external recipient (also bcc) in a single mail.

>1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?


yes

>2) Might you be able to change functionality so that we have the option to :
>   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 

What else is this function doing?

   b) remove these lines from files that are resent (for the same reason)


This was already done.

>My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

done


Thomas




Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        31.05.2017 23:56
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <[hidden email]> wrote:
Hi all,

fixed in assp 2.5.6 build 17151:



changed:


AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options


'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'

 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".

 If not disabled, both header lines will be added for all emails to all collected .eml files.



Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

Thomas Eckardt/eck
In reply to this post by K Post
>It doesn't seem to check what the value of AddIntendedForHeader is

in the GUI read:

......If not disabled, both header lines will be added for all emails to all collected .eml files.

This code part is for the .eml files.

>
but it's also adding it to the stream that the MTA sees.

NO!
Beause this feature will make the mail stream and the stored .eml file different in case of the settings 'outgoing' or 'incoming and local', the default setting is 'All' (like it was for years now).

>all of the recipients show x-assp-intended-for lines,

NO - this depends on the setting of 'AddIntendedForHeader' - 0,1,2,3
I don't know what and why we are talking about here!?

>The issue I'm seeing

Where in the code? I don't see this.

    if (($this->{relayok} | (! $this->{relayok} * 2)) & $AddIntendedForHeader) {      # (0/1) | ((1/0) * 2) & (0/1/2/3)
        $this->{myheader}.= "X-Assp-Envelope-From: $this->{mailfrom}\r\n"
            if $this->{mailfrom} && $header !~ /X-Assp-Envelope-From: \Q$this->{mailfrom}\E/;
        for (split(/ /o,$this->{rcpt})) {
            $this->{myheader}.= "X-Assp-Intended-For: $_\r\n"
                if $_ && $header !~ /X-Assp-Intended-For: \Q$_\E/i;
        }
    }

the next version will have a change in this code part - but this makes no functional difference

    my $rok = $this->{relayok} ? 1 : 0;
    if (($rok | (! ($rok << 1))) & $AddIntendedForHeader) {      # (0/1) | ((1/0) * 2) & (0/1/2/3)
.....

problem: your exchange server makes the BCC addresses visable - in case it removes all BCC information. You can't expect that anyone behind exchange will respect anything (BCC) which he does'nt know.

I wrote some more here ..............., but removed it, because this thread is senseless. This feature works like expected - nothing to change + nothing to talk about.

Thomas



Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        04.06.2017 02:44
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




With this new version, the gui says "both header lines will be added for all emails to all collected .eml files"   The issue I'm seeing is that if AddIntendedForHeader is not disabled, not only does it add it to the eml file as expected, but it's also adding it to the stream that the MTA sees.  I see the value of having this in the eml files in the mailstore, but putting the intended for header into the header that the recipient can see when the message was BCC'ed is presenting a big problem.  

We smart host relay from Exchange through ASSP.  Exchange and lots of other mail clients when setup with a smarthost send a single message to the smarthost for multiple recipients.  If some are bcc'ed, that's still a single message.  It's not unusual for our staff to send a message to 50 bcc addresses.  They leave the outgoing MTA just fine, but because they went through the ASSP relay port (or were sent directly through the standard port for pop/smtp clients), all of the recipients show x-assp-intended-for lines, negating the purpose of bcc.

If I disable AddIntendedForHeader, it doesn't show, but then it's not recorded in the eml file either, which is better than revealing bcc recipients, but sub-optimal.

Even if I could change the behavior of the way that Exchange sends to a smarthost (which I can't), we can't control how other MTA's send to us.  If someone outside sends a single message with one to and one bcc to us, the recipient can see the bcc recipient in the header, which betrays the trust that the sender had in us - (and maybe violates RFC's ???)

SO - the real question is if there's a possibility to essentially remove the AddIntendedForHeader from the gui and ALWAYS add the intended for and envelope from to the eml file on the ASSP server but NOT send these lines to the receiving MTA under any circumstance.

And if this is possible, what downside is there to not having these lines in the email header except in the corpus.  Would spam reporting be impacted?

Line 44625 has    if ($AddIntendedForHeader)  and then it prints the intended for header lines.  It doesn't seem to check what the value of AddIntendedForHeader is, so if it's not disabled, it'll print it regardless of inbound or outbound.  I don't know if this is an oversight or if I'm just not understanding correctly.



On Thu, Jun 1, 2017 at 8:26 PM, K Post <nntp.post@...> wrote:
Shucks, I thought I had finally found a bug that wasn't due to my idiocy (or the idiocy of other software that I'm using)

If you don't mind,more questions / comments:

1) In this new version, did the code change to now insure that the X-ASSP-intendedfor lines are now not in the MTA stream no matter how stupid the sending MTA is?  I ask because I definitely wasn't seeing that behavior before, the intended for line was in the header that the MTA delivers to the inbox.

2) I think the problem is that if using a smarthost with Exchange, it routes single messages to the smarthost as one, regardless of the domain(s) of the recipients.  Have you seen this before?  My gut says that ASSP has never considered this before and we've probably  been giving away bcc info for years.



On Thu, Jun 1, 2017 at 1:10 AM, Thomas Eckardt <Thomas.Eckardt@...> wrote:
>Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

No - it works around your bad mail server config.
Your MTA should send the mail as it was created (except local recipients) - or a single mail to each recipient - not sending it to each external recipient (also bcc) in a single mail.

>1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?


yes

>2) Might you be able to change functionality so that we have the option to :
>   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 

What else is this function doing?

   b) remove these lines from files that are resent (for the same reason)


This was already done.

>My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  


done


Thomas





Von:        
K Post <nntp.post@...>
An:        
ASSP development mailing list <[hidden email]>
Datum:        
31.05.2017 23:56
Betreff:        
Re: [Assp-test] fixes in assp 2.5.6 build 17151





Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <
Thomas.Eckardt@...> wrote:
Hi all,


fixed in assp 2.5.6 build 17151:



changed:


AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options


'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'

 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".

 If not disabled, both header lines will be added for all emails to all collected .eml files.



Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

Thomas Eckardt/eck
In reply to this post by K Post
>I played some more, if comment out 44625

Looking for chiquita bananas at the K2 would be the same way senseless.

Thomas





Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        04.06.2017 03:03
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




I played some more, if comment out 44625 and the closing } several lines down, ASSP seems to do what I want - add the intended for line to the eml file ALWAYS but never into the MTA stream.  is there a reason we wouldn't always want the system to work this way?

On Sat, Jun 3, 2017 at 8:43 PM, K Post <nntp.post@...> wrote:
With this new version, the gui says "both header lines will be added for all emails to all collected .eml files"   The issue I'm seeing is that if AddIntendedForHeader is not disabled, not only does it add it to the eml file as expected, but it's also adding it to the stream that the MTA sees.  I see the value of having this in the eml files in the mailstore, but putting the intended for header into the header that the recipient can see when the message was BCC'ed is presenting a big problem.  

We smart host relay from Exchange through ASSP.  Exchange and lots of other mail clients when setup with a smarthost send a single message to the smarthost for multiple recipients.  If some are bcc'ed, that's still a single message.  It's not unusual for our staff to send a message to 50 bcc addresses.  They leave the outgoing MTA just fine, but because they went through the ASSP relay port (or were sent directly through the standard port for pop/smtp clients), all of the recipients show x-assp-intended-for lines, negating the purpose of bcc.

If I disable AddIntendedForHeader, it doesn't show, but then it's not recorded in the eml file either, which is better than revealing bcc recipients, but sub-optimal.

Even if I could change the behavior of the way that Exchange sends to a smarthost (which I can't), we can't control how other MTA's send to us.  If someone outside sends a single message with one to and one bcc to us, the recipient can see the bcc recipient in the header, which betrays the trust that the sender had in us - (and maybe violates RFC's ???)

SO - the real question is if there's a possibility to essentially remove the AddIntendedForHeader from the gui and ALWAYS add the intended for and envelope from to the eml file on the ASSP server but NOT send these lines to the receiving MTA under any circumstance.

And if this is possible, what downside is there to not having these lines in the email header except in the corpus.  Would spam reporting be impacted?

Line 44625 has    if ($AddIntendedForHeader)  and then it prints the intended for header lines.  It doesn't seem to check what the value of AddIntendedForHeader is, so if it's not disabled, it'll print it regardless of inbound or outbound.  I don't know if this is an oversight or if I'm just not understanding correctly.



On Thu, Jun 1, 2017 at 8:26 PM, K Post <nntp.post@...> wrote:
Shucks, I thought I had finally found a bug that wasn't due to my idiocy (or the idiocy of other software that I'm using)

If you don't mind,more questions / comments:

1) In this new version, did the code change to now insure that the X-ASSP-intendedfor lines are now not in the MTA stream no matter how stupid the sending MTA is?  I ask because I definitely wasn't seeing that behavior before, the intended for line was in the header that the MTA delivers to the inbox.

2) I think the problem is that if using a smarthost with Exchange, it routes single messages to the smarthost as one, regardless of the domain(s) of the recipients.  Have you seen this before?  My gut says that ASSP has never considered this before and we've probably  been giving away bcc info for years.



On Thu, Jun 1, 2017 at 1:10 AM, Thomas Eckardt <Thomas.Eckardt@...> wrote:
>Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

No - it works around your bad mail server config.
Your MTA should send the mail as it was created (except local recipients) - or a single mail to each recipient - not sending it to each external recipient (also bcc) in a single mail.

>1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?


yes

>2) Might you be able to change functionality so that we have the option to :
>   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 

What else is this function doing?

   b) remove these lines from files that are resent (for the same reason)


This was already done.

>My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  


done


Thomas





Von:        
K Post <nntp.post@...>
An:        
ASSP development mailing list <[hidden email]>
Datum:        
31.05.2017 23:56
Betreff:        
Re: [Assp-test] fixes in assp 2.5.6 build 17151





Thank you for this.  Does this mean that I wasn't crazy at least on this one point?  Hurray!

You're going to be shocked by this, but I have questions :)

1) What does All Adds (option 3) mean?  Is that like incoming and outgoing (or what was previously just what the check box did)?

2) Might you be able to change functionality so that we have the option to :
   a) add this info to the eml files for admin use and resents but NOT write them to the stream that the MTA sees (so that it doesn't show up in the received mail header and users can't see this?) and 
   b) remove these lines from files that are resent (for the same reason)

My big fear is internal mail where a single message might be from internal user 1 to internal user 2 with a bcc to user 2's boss.  If it's a bcc, user 2 shohuldn't know that the boss was included, and looking at the header will show that.  

Interested in your thoughts.

On Wed, May 31, 2017 at 1:50 AM, Thomas Eckardt <
Thomas.Eckardt@...> wrote:
Hi all,


fixed in assp 2.5.6 build 17151:



changed:


AddIntendedForHeader is switched from a checkbox to a listbox in the GUI to support additionally options


'AddIntendedForHeader','Add Envelope-Recipient Header','0:disabled|1:outgoing|2:incoming and local|3:all'

 'Adds (according to the setting) two lines to the email header: "X-Assp-Intended-For: user@domain" and "X-Assp-Envelope-From: user@domain".

 If not disabled, both header lines will be added for all emails to all collected .eml files.



Thomas


DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list

[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
Thomas,

I figured I was going to wind up angering you, and I'm sincerely sorry that I have.  I'm fearful that I'm going to infuriate you further and never get an answer here, but please, I'm begging you to take a breath, stop seeming so angry with me, and give more consideration to this.  This is a very real problem for us - and all of the others who don't realize that bcc recipients are being disclosed by ASSP under certain circumstances.

I wish there was a way for me to discuss my ideas without offending or angering you.  I'll remind you of the same thing that I always do: everyone here, especially me is extraordinarily grateful to you for the work you have done and continue to do to support ASSP.  When we ask questions or make suggestions, it's not a personal attack or a suggestion that you're wrong, imperfect, or anything like that.  We're trying to be helpful.  Or we're trying to understand better the logic being used, why something is some way, and maybe even contribute to make ASSP even better.

I do not for a second believe that you'd prefer us to keep quiet when we think we've found and an error or think we have an idea that might help ASSP.   Granted, we're usually wrong, especially me, but that doesn't mean that we're deserving of a curt response, no matter how foolish you believe the question/point to be.  This isn't supposed to be an adversarial relationship between us here.   We're all on the same team fighting spammers.  

So I will continue here, in the hopes that you will reconsider continuing this conversation.  I'm sorry that you're finding the discussion senseless, but I believe I've explained my concerns clearly and respectfully.  I haven't received enough of an answer to understand why I'm wrong or why you don't think that what I'm proposing would be better logic for ASSP to follow.


1) You wrote:
>problem: your exchange server makes the BCC addresses visable - in case it removes all BCC information. You can't expect that anyone behind exchange will respect anything (BCC) which he does'nt know. 

I feel like I might not have been clear enough as to what I'm seeing.  I'm not talking about seeing "BCC: [hidden email]" in the email header.  I'm talking about ASSP puting the intended for header.

I agree that Exchange makes the bcc addresses visible to ASSP, but that's in the envelope only, it's not in the visible header.  It's ASSP that is writing the intended for header lines and exposing the information to the end user.    I know you would prefer that all mail servers send bcc messages separately.  That would solve this problem, but that's not how all mail servers behave and the RFC's that I've skimmed over allow them to work this way.  Exchange and other servers assume that when it passes recipient info in the envelope only and not in the message header that whatever server is receiving it will honor the bcc request and not disclose these recipients.  Is it unreasonable to ask ASSP to do this??   And moreover, what's the upside to keeping ASSP the way it is?

I don't know what you mean by "You can't expect that anyone behind exchange will respect anything (BCC) which he does'nt know."  You can't be suggesting that no Exchange user should expect BCC to keep recipients blind.  And how about basic pop3/smtp email users who send directly via SMTP through ASSP using client software like Outlook or Thunderbird?  It's not like a message sent with multiple bcc recipients through a users email software would result in multiple messages going through ASSP.  I tested this with a simple Thunderbird setup and with a direct telnet session to ASSP's port 25.  

helo test
mail from: [hidden email]
data

subject: test

message
.

ASSP adds 3 intended for headers if AddIntendedFor isn't disabled. User [hidden email] who wasn't bcc'ed can see that [hidden email] and [hidden email] were bcc'ed by looking at the intended for headers.


Even if this were an Exchange specific problem, it's not like we're the only ones using Exchange.  Other servers send a single message to a defined smarthost even when there are bcc recipients.  I tested hmailserver too, and it does the same thing.  I believe those are two pretty common setups - I'm not going to be the only one affected here, it's just as if no one else has recognized this before.  

I understand that this is the way that its been for years.  Is there no room for improvement here just because this is the way that it's been working for a long time?  I didn't realize that we were inadvertently exposing all bcc recipients in the x-ASSP-Intended-For header, but now that I do, we can't continue like this.  I'm lucky that this doesn't seem to have gotten anyone in trouble before.  Whether or not you had considered this before, don't you agree that this is a problem?  


I would greatly appreciate it if you could explain why the current logic used by ASSP is preferable to what I'm proposing.   Wouldn't having the info in the eml file give ASSP everything it needs to do resends, analysis etc, but not having it in the stream honor the sender's request to have certain recipients not be disclosed?  What's the downside and why isn't this a better way of doing it vs what we have now?  


2) My suggestion, which you essentially said is crazy, to always write the header to the .eml files so that ASSP can do its thing later, but never write the intended for header to the actual stream still makes sense to me.  Could you explain why having these lines in the stored files but not in what's sent to the MTA is bad/dangerous?  



3) You're the expert here which is why I'm asking vs telling.  You're also the perl guru.  All I can do is try - 

From what I can tell, this is where the header is added to the email stream to the MTA.
34656 if (($this->{relayok} | (! $this->{relayok} * 2)) & $AddIntendedForHeader) { # (0/1) | ((1/0) * 2) & (0/1/2/3)
34657 $this->{myheader}.= "X-Assp-Envelope-From: $this->{mailfrom}\r\n"
34658 if $this->{mailfrom} && $header !~ /X-Assp-Envelope-From: \Q$this->{mailfrom}\E/;
34659 for (split(/ /o,$this->{rcpt})) {
34660 $this->{myheader}.= "X-Assp-Intended-For: $_\r\n"
34661 if $_ && $header !~ /X-Assp-Intended-For: \Q$_\E/i;
34662 }
34663 }
It seems like that's working as expected, adding the header depending on how AddIntendedForHeader is set.   I must admit that I don't see where ASSP is making a distinction between incoming only, outgoing only, or all, but that doesn't matter in my case, I don't want ASSP to put it into the stream in any case, so  I've got it set to disabled.  It seems to me that the value set to 1, 2, or 3 would all be true and the 


And here is where the eml file is stored (I referenced this before).  
44625 if ($AddIntendedForHeader) {
44626 $myheader .= "X-Assp-Envelope-From: $Con{$fh}->{mailfrom}\r\n"
44627 if $Con{$fh}->{mailfrom} && $myheader !~ /X-Assp-Envelope-From: \Q$Con{$fh}->{mailfrom}\E/;
44628 for (split(/ /o,$Con{$fh}->{rcpt})) {
44629 $myheader .= "X-Assp-Intended-For: $_\r\n"
44630 if $_ && $myheader !~ /X-Assp-Intended-For: \Q$_\E/i;
44631 }
44632 }
 It's only checking for a disabled setting of AddIntendedForHeader.    I assume that ASSP honors settings of 1 or 2 for AddIntendedFor and considers the direction of the mail (and that I just don't see where this is done).  If that's the case, wouldn't these 2 sections of code result in a eml file that is potentially different from the stream sent to the MTA if AddIntendedFor is 1 or 2 which you suggested might be bad?   Again, I don't know why that's a bad thing if we're trying to keep bcc information blind.   Why wouldn't we always want to have this envelope info in the .eml file so that resends work, etc?  I'm talking about having it regardless of the setting of AddIntendedForHeader.

End users don't need to see the intendedforheader, but the eml files need it...

And it's not like this is a difficult change to make, delete lines 44625 and 44632, that's it. After that, if an admin wants to have into inserted in the the MTA stream, they set AddIntendedForHeader to something other than disabled, but ASSP will always record the envelope information in the eml file for use later.  Then just edit the description of the AddIntendedFor option:

X-Assp-Intended-For and X-Assp-Envelope-From are always recorded in eml files.  This option determines if this information is also added to the delivered message, visible to the recipient.  Warning: enabling this option potentially exposes BCC recipients to other recipients if the sending server or client opts to send a single message with multiple recipients.



If you've made it this far, again THANK YOU.  I hope I've explained myself more clearly here and that you'll either explain to me why this isn't a good idea or use my concept to modify ASSP's logic.

Ken


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

Thomas Eckardt/eck
An MTA behind your exchange may do the following

   Received: from .... by ....date.... for user1, user 2 user 3

again : your exchange makes the recipients visable - and visable to each other by combining BCC with TO and CC addresses as envelope recipients in a single mail

no problem: 'AddIntendedForHeader' can be set as required - use 'incoming and local'


>ASSP adds 3 intended for headers if AddIntendedFor isn't disabled. User one@... who wasn't bcc'ed can see that two@... and three@... were bcc'ed by looking at the intended for headers.

This is wrong! Only email admins have access to .eml files. Headers are only added to the mail stream as configured. .elm files will contain the headers (if configured) for future internal processing.


>I would greatly appreciate it if you could explain why the current logic used by ASSP is preferable to what I'm proposing.

ASSP is exactly doing what you want - ALL THE TIME with build 17151.
No, I don't want to explain why and where these header lines are required. Simply count the occurrence of X-Assp-Intended-For and X-Assp-Envelope-From in the code.

Thomas
thread closed!




Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        04.06.2017 19:27
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Thomas,

I figured I was going to wind up angering you, and I'm sincerely sorry that I have.  I'm fearful that I'm going to infuriate you further and never get an answer here, but please, I'm begging you to take a breath, stop seeming so angry with me, and give more consideration to this.  This is a very real problem for us - and all of the others who don't realize that bcc recipients are being disclosed by ASSP under certain circumstances.

I wish there was a way for me to discuss my ideas without offending or angering you.  I'll remind you of the same thing that I always do: everyone here, especially me is extraordinarily grateful to you for the work you have done and continue to do to support ASSP.  When we ask questions or make suggestions, it's not a personal attack or a suggestion that you're wrong, imperfect, or anything like that.  We're trying to be helpful.  Or we're trying to understand better the logic being used, why something is some way, and maybe even contribute to make ASSP even better.

I do not for a second believe that you'd prefer us to keep quiet when we think we've found and an error or think we have an idea that might help ASSP.   Granted, we're usually wrong, especially me, but that doesn't mean that we're deserving of a curt response, no matter how foolish you believe the question/point to be.  This isn't supposed to be an adversarial relationship between us here.   We're all on the same team fighting spammers.  

So I will continue here, in the hopes that you will reconsider continuing this conversation.  I'm sorry that you're finding the discussion senseless, but I believe I've explained my concerns clearly and respectfully.  I haven't received enough of an answer to understand why I'm wrong or why you don't think that what I'm proposing would be better logic for ASSP to follow.


1) You wrote:
>problem: your exchange server makes the BCC addresses visable - in case it removes all BCC information. You can't expect that anyone behind exchange will respect anything (BCC) which he does'nt know. 

I feel like I might not have been clear enough as to what I'm seeing.  I'm not talking about seeing "BCC: user@..." in the email header.  I'm talking about ASSP puting the intended for header.

I agree that Exchange makes the bcc addresses visible to ASSP, but that's in the envelope only, it's not in the visible header.  It's ASSP that is writing the intended for header lines and exposing the information to the end user.    I know you would prefer that all mail servers send bcc messages separately.  That would solve this problem, but that's not how all mail servers behave and the RFC's that I've skimmed over allow them to work this way.  Exchange and other servers assume that when it passes recipient info in the envelope only and not in the message header that whatever server is receiving it will honor the bcc request and not disclose these recipients.  Is it unreasonable to ask ASSP to do this??   And moreover, what's the upside to keeping ASSP the way it is?

I don't know what you mean by "You can't expect that anyone behind exchange will respect anything (BCC) which he does'nt know."  You can't be suggesting that no Exchange user should expect BCC to keep recipients blind.  And how about basic pop3/smtp email users who send directly via SMTP through ASSP using client software like Outlook or Thunderbird?  It's not like a message sent with multiple bcc recipients through a users email software would result in multiple messages going through ASSP.  I tested this with a simple Thunderbird setup and with a direct telnet session to ASSP's port 25.  

helo test
mail from: me@...
rcpt to: one@...
rcpt to: two@...
rcpt to: [hidden email]
data

subject: test
to: one@...

message
.

ASSP adds 3 intended for headers if AddIntendedFor isn't disabled. User one@... who wasn't bcc'ed can see that two@... and three@... were bcc'ed by looking at the intended for headers.


Even if this were an Exchange specific problem, it's not like we're the only ones using Exchange.  Other servers send a single message to a defined smarthost even when there are bcc recipients.  I tested hmailserver too, and it does the same thing.  I believe those are two pretty common setups - I'm not going to be the only one affected here, it's just as if no one else has recognized this before.  

I understand that this is the way that its been for years.  Is there no room for improvement here just because this is the way that it's been working for a long time?  I didn't realize that we were inadvertently exposing all bcc recipients in the x-ASSP-Intended-For header, but now that I do, we can't continue like this.  I'm lucky that this doesn't seem to have gotten anyone in trouble before.  Whether or not you had considered this before, don't you agree that this is a problem?  


I would greatly appreciate it if you could explain why the current logic used by ASSP is preferable to what I'm proposing.   Wouldn't having the info in the eml file give ASSP everything it needs to do resends, analysis etc, but not having it in the stream honor the sender's request to have certain recipients not be disclosed?  What's the downside and why isn't this a better way of doing it vs what we have now?  


2) My suggestion, which you essentially said is crazy, to always write the header to the .eml files so that ASSP can do its thing later, but never write the intended for header to the actual stream still makes sense to me.  Could you explain why having these lines in the stored files but not in what's sent to the MTA is bad/dangerous?  



3) You're the expert here which is why I'm asking vs telling.  You're also the perl guru.  All I can do is try - 

From what I can tell, this is where the header is added to the email stream to the MTA.
34656
if (($this->{relayok} | (! $this->{relayok} * 2)) & $AddIntendedForHeader) { # (0/1) | ((1/0) * 2) & (0/1/2/3)
34657
$this->{myheader}.= "X-Assp-Envelope-From: $this->{mailfrom}\r\n"
34658
if $this->{mailfrom} && $header !~ /X-Assp-Envelope-From: \Q$this->{mailfrom}\E/;
34659
for (split(/ /o,$this->{rcpt})) {
34660
$this->{myheader}.= "X-Assp-Intended-For: $_\r\n"
34661
if $_ && $header !~ /X-Assp-Intended-For: \Q$_\E/i;
34662
}
34663
}

It seems like that's working as expected, adding the header depending on how AddIntendedForHeader is set.   I must admit that I don't see where ASSP is making a distinction between incoming only, outgoing only, or all, but that doesn't matter in my case, I don't want ASSP to put it into the stream in any case, so  I've got it set to disabled.  It seems to me that the value set to 1, 2, or 3 would all be true and the 


And here is where the eml file is stored (I referenced this before).  
44625
if ($AddIntendedForHeader) {
44626
$myheader .= "X-Assp-Envelope-From: $Con{$fh}->{mailfrom}\r\n"
44627
if $Con{$fh}->{mailfrom} && $myheader !~ /X-Assp-Envelope-From: \Q$Con{$fh}->{mailfrom}\E/;
44628
for (split(/ /o,$Con{$fh}->{rcpt})) {
44629
$myheader .= "X-Assp-Intended-For: $_\r\n"
44630
if $_ && $myheader !~ /X-Assp-Intended-For: \Q$_\E/i;
44631
}
44632
}

 It's only checking for a disabled setting of AddIntendedForHeader.    I assume that ASSP honors settings of 1 or 2 for AddIntendedFor and considers the direction of the mail (and that I just don't see where this is done).  If that's the case, wouldn't these 2 sections of code result in a eml file that is potentially different from the stream sent to the MTA if AddIntendedFor is 1 or 2 which you suggested might be bad?   Again, I don't know why that's a bad thing if we're trying to keep bcc information blind.   Why wouldn't we always want to have this envelope info in the .eml file so that resends work, etc?  I'm talking about having it regardless of the setting of AddIntendedForHeader.

End users don't need to see the intendedforheader, but the eml files need it...

And it's not like this is a difficult change to make, delete lines 44625 and 44632, that's it. After that, if an admin wants to have into inserted in the the MTA stream, they set AddIntendedForHeader to something other than disabled, but ASSP will always record the envelope information in the eml file for use later.  Then just edit the description of the AddIntendedFor option:

X-Assp-Intended-For and X-Assp-Envelope-From are always recorded in eml files.  This option determines if this information is also added to the delivered message, visible to the recipient.  Warning: enabling this option potentially exposes BCC recipients to other recipients if the sending server or client opts to send a single message with multiple recipients.



If you've made it this far, again THANK YOU.  I hope I've explained myself more clearly here and that you'll either explain to me why this isn't a good idea or use my concept to modify ASSP's logic.

Ken
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
Your last email was quite helpful and is helping me to understand better.  Thank you again for that.  And I found a mistake in my testing/understanding by retrying some things and re-reading what you've already said multiple times.

Please, bear with me through just a few more questions and point and then I think we'll be done.

It's no question that Exchange is sending this info in the envelope, but it's allowed to do so, we can't change that, nor can we change what other external SMTP servers do.  
And it's worse than "just" Exchange, email clients that send through ASSP's smtp port also send a single message for multiple bcc recipients.

But, and this is important, I must not have tested incorrectly, because when now when I set AddIntendedFor to incoming and local, I get exactly what you describe, the intended for line does NOT appear in the email client, but does show up in the eml files.  
17151 resolves the issue with Exchange and clients sending a single message for multiple bcc recipients.  That's exactly what I want.   Maybe I didn't apply the changes when testing or something. Whatever the case, this is quite relieving.

Just 2 more quick questions:

1) I think there's going to be serious misunderstanding by people reading the GUI as to the AddIntendedFor options.  Option 0, disabled, is clear, don't ever add the headers.  Option 3, all is also clear, always add the headers.  
But what is being tested for "outgoing" vs "incoming and local"     I'm sure this question sounds completely stupid to you, but I don't understand your options.  

2) You previously mentioned that having the mail stream differ from the stored eml is bad, or at least I interpreted it that way.  It seems like with the incoming/local only option for AddIntendedFor, the stream and stored file could be different.  I don't see a problem with this, but I'm worried that you said there could be.  Could you explain?

Thanks again for your patience.
Ken



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

Daniel Miller

I have a question on this as well.  I just tested this (we do NOT use Exchange, only Postfix) and found:

- with a setting of "ALL" - BCC is indeed exposed for all mails.

- with a setting of "incoming and local" - BCC is not exposed - and neither are the other recipients.

My test:

from both internal and external clients for my domain, I sent a message to an internal user with a BCC to another.  With "ALL" - the mails included the headers that showed both recipients.

with "incoming and local" - I saw no headers for either recipient

with "incoming and local" - a message from Gmail had a single intended-for header in each mail - showing the individual recipient.  The BCC target did not see the public target, nor the public target see the BCC target.

Daniel

    
On 6/5/2017 8:33 AM, K Post wrote:
Your last email was quite helpful and is helping me to understand better.  Thank you again for that.  And I found a mistake in my testing/understanding by retrying some things and re-reading what you've already said multiple times.

Please, bear with me through just a few more questions and point and then I think we'll be done.

It's no question that Exchange is sending this info in the envelope, but it's allowed to do so, we can't change that, nor can we change what other external SMTP servers do.  
And it's worse than "just" Exchange, email clients that send through ASSP's smtp port also send a single message for multiple bcc recipients.

But, and this is important, I must not have tested incorrectly, because when now when I set AddIntendedFor to incoming and local, I get exactly what you describe, the intended for line does NOT appear in the email client, but does show up in the eml files.  
17151 resolves the issue with Exchange and clients sending a single message for multiple bcc recipients.  That's exactly what I want.   Maybe I didn't apply the changes when testing or something. Whatever the case, this is quite relieving.

Just 2 more quick questions:

1) I think there's going to be serious misunderstanding by people reading the GUI as to the AddIntendedFor options.  Option 0, disabled, is clear, don't ever add the headers.  Option 3, all is also clear, always add the headers.  
But what is being tested for "outgoing" vs "incoming and local"     I'm sure this question sounds completely stupid to you, but I don't understand your options.  

2) You previously mentioned that having the mail stream differ from the stored eml is bad, or at least I interpreted it that way.  It seems like with the incoming/local only option for AddIntendedFor, the stream and stored file could be different.  I don't see a problem with this, but I'm worried that you said there could be.  Could you explain?

Thanks again for your patience.
Ken




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

Thomas Eckardt/eck
In reply to this post by K Post
>But what is being tested for "outgoing" vs "incoming and local"

Nothing is tested using these header lines - these headers are recorded for future processing like rebuildspamdb, analyzing, resend, reports, GUI actions ....

>2) ... I don't see a problem with this

me too
But it may confuse some admins, if they see different content in the mail stream (client received mail) and the stored .eml file.

Thomas



Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        05.06.2017 17:35
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Your last email was quite helpful and is helping me to understand better.  Thank you again for that.  And I found a mistake in my testing/understanding by retrying some things and re-reading what you've already said multiple times.

Please, bear with me through just a few more questions and point and then I think we'll be done.

It's no question that Exchange is sending this info in the envelope, but it's allowed to do so, we can't change that, nor can we change what other external SMTP servers do.  
And it's worse than "just" Exchange, email clients that send through ASSP's smtp port also send a single message for multiple bcc recipients.

But, and this is important, I must not have tested incorrectly, because when now when I set AddIntendedFor to incoming and local, I get exactly what you describe, the intended for line does NOT appear in the email client, but does show up in the eml files.  
17151 resolves the issue with Exchange and clients sending a single message for multiple bcc recipients.  That's exactly what I want.   Maybe I didn't apply the changes when testing or something. Whatever the case, this is quite relieving.

Just 2 more quick questions:

1) I think there's going to be serious misunderstanding by people reading the GUI as to the AddIntendedFor options.  Option 0, disabled, is clear, don't ever add the headers.  Option 3, all is also clear, always add the headers.  
But what is being tested for "outgoing" vs "incoming and local"     I'm sure this question sounds completely stupid to you, but I don't understand your options.  

2) You previously mentioned that having the mail stream differ from the stored eml is bad, or at least I interpreted it that way.  It seems like with the incoming/local only option for AddIntendedFor, the stream and stored file could be different.  I don't see a problem with this, but I'm worried that you said there could be.  Could you explain?

Thanks again for your patience.
Ken

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixes in assp 2.5.6 build 17151

K Post
Thomas,
Would you consider changing the options (really just the descriptions) for the AddIntendedForHeader?  Maybe  something like:

Disabled
Include only in the stored .eml file
Include in both the stored .eml file and the stream

and add the note that inserting this stream may inadvertently expose BCC recipients?


Daniel,
For the mail from gmail (where I also tested), I'm not surprised that the bcc intended for header is included for the mail to the bcc recipient, but not for the non-bcc recipient. Gmail's server send individual messages to each bcc recipient.  That's not required by the RFC, but it's not prohibited either.  The issue at hand is that we can't guarantee that mail servers will do this (Exchange doesn't, maybe postfix doesn't either).  If they send one message with multiple bcc recipients in the envelope and the AddIntendedForHeader option is set to ALL, those bcc recipients will be exposed.


I know I've dodged a big bullet having had ASSP running like this for years.  I guess no one ever looked, or no one ever said anything.    I'm super relieved that ASSP has the in the middle option now - record only for .eml and not to the stream.



On Tue, Jun 6, 2017 at 3:29 AM, Thomas Eckardt <[hidden email]> wrote:
>But what is being tested for "outgoing" vs "incoming and local"

Nothing is tested using these header lines - these headers are recorded for future processing like rebuildspamdb, analyzing, resend, reports, GUI actions ....

>2) ... I don't see a problem with this

me too
But it may confuse some admins, if they see different content in the mail stream (client received mail) and the stored .eml file.

Thomas



Von:        K Post <[hidden email]>
An:        ASSP development mailing list <[hidden email]>
Datum:        05.06.2017 17:35
Betreff:        Re: [Assp-test] fixes in assp 2.5.6 build 17151




Your last email was quite helpful and is helping me to understand better.  Thank you again for that.  And I found a mistake in my testing/understanding by retrying some things and re-reading what you've already said multiple times.

Please, bear with me through just a few more questions and point and then I think we'll be done.

It's no question that Exchange is sending this info in the envelope, but it's allowed to do so, we can't change that, nor can we change what other external SMTP servers do.  
And it's worse than "just" Exchange, email clients that send through ASSP's smtp port also send a single message for multiple bcc recipients.

But, and this is important, I must not have tested incorrectly, because when now when I set AddIntendedFor to incoming and local, I get exactly what you describe, the intended for line does NOT appear in the email client, but does show up in the eml files.  
17151 resolves the issue with Exchange and clients sending a single message for multiple bcc recipients.  That's exactly what I want.   Maybe I didn't apply the changes when testing or something. Whatever the case, this is quite relieving.

Just 2 more quick questions:

1) I think there's going to be serious misunderstanding by people reading the GUI as to the AddIntendedFor options.  Option 0, disabled, is clear, don't ever add the headers.  Option 3, all is also clear, always add the headers.  
But what is being tested for "outgoing" vs "incoming and local"     I'm sure this question sounds completely stupid to you, but I don't understand your options.  

2) You previously mentioned that having the mail stream differ from the stored eml is bad, or at least I interpreted it that way.  It seems like with the incoming/local only option for AddIntendedFor, the stream and stored file could be different.  I don't see a problem with this, but I'm worried that you said there could be.  Could you explain?

Thanks again for your patience.
Ken

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test




DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no known virus in this email!
*******************************************************


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/assp-test
Loading...