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
o...@domain.org who wasn't bcc'ed can see that t...@domain.org and
th...@otherdomain.org 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 <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
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: u...@domain.org" 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: m...@ourcharity.org
rcpt to: o...@domain.org
rcpt to: t...@domain.org
rcpt to: th...@otherdomain.org
data
subject: test
to: o...@domain.org
message
.
ASSP adds 3 intended for headers if AddIntendedFor isn't disabled. User
o...@domain.org who wasn't bcc'ed can see that t...@domain.org and
th...@otherdomain.org 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
Assp-test@lists.sourceforge.net
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
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
