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
