On Fri, May 24, 2002 at 10:41:20PM +0200, Mark Martinec wrote: | D-man, (and others), | | |On Tue, May 21, 2002 at 09:36:41PM +0200, Mark Martinec wrote: | |> The SMTP envelope address (sender and recipients) is quite | |> a different thing than the RFC822 addresses inside the mail header. | | Yes. | | | |> it is a requirement for a MTA that it removes 'Bcc:' addresses from | |> the header! | | NO. It is a requirement that the MTA *NOT* do anything to the data in | | the DATA part of the SMTP session apart from escaping a line beginning | | with '.' and prepending a Received: header. It is the MUA's | | responsibility not to insert that header in the first place. (It's | | kind of obvious that you don't send someone data you don't want them | | to have.) | | Not necessarily - depends on how MUA passes message to MTA. | MUA can pass envelope addresses separately, otherwise MTA must derive | them by parsing RFC2822 header, and remove Bcc while doing it.
That sounds bad to me. I clearly recall a section of RFC821 stating
that an MTA MUST not mangle a message in any way. It also sounds bad
to have something read the message to figure out who it is for.
That's what the envelope is for :-). I know that exim won't derive
the envelope from a message nor will it strip out anything (including
Bcc:).
| This is covered by:
|
| RFC2821 / APPENDIX B / 1.
| ... Any BCC fields SHOULD then be removed from the headers.
Interesting addendum. I suppose that was added
| RFC2822
| 3.6.3. [...] In the second case, recipients specified in the
| "To:" and "Cc:" lines each are sent a copy of the message with
| the "Bcc:" line removed as above, but the recipients on the "Bcc:"
| line get a separate copy of the message containing a "Bcc:" line.
This sounds like it is the MUA's job to properly package the message
for sending.
The analogy I like is the Post Office. The PO requires you to package
your letters in a properly addressed envelope before they will handle
it. They will not open your envelope and tamper with your letter at
all. If you want to send separate letters to separate people (ie with
or without Bcc: notes) it is your job to correctly write the letters
and package them in the envelopes.
| |> There is probably an extra benefit of having envelope addresses
| |> available to SA rules.
|
| | Maybe. The simplest way is to tell your MTA to add the Return-Path:
| | and Envelope-To: headers and make rules for them in SA.
| | [...]
| | It would be better to have envelope handing in the MTA and Message
| | handling in the other stuff.
|
| Return-path should only be added to the header by the delivery agent.
| If filtering is done on a mail hub, it must _not_ add the Return-path
| just to satisfy some scanner's curiosity, as otherwise we'll end up
| with two such headers.
|
| Envelope-To or similar may only be added by the final delivery
| agent, individually for each recipient. Mail hub must not add such
| header, as it would violate the privacy and reveal the full list
| of envelope recipient to all recipients, which is not permitted.
Ok, that makes sense.
| I find it too limiting to restrict spam filter to require it to see
| only RFC2822 message and ignore other information if available.
| True, it is not available in all configurations, but if it _is_ available
| (like when spam filter is called from the central mail hub), any additional
| information may be of value. If it were phases of the Moon to have influence
| on spam-score, so why not.
Alright, make a command-line option for spamc through which the
envelope can be specified.
| | If you want to whitelist an envelope
| | sender, then don't feed the message to SA in the first place.
|
| Some arguments for not having similar whitelists in two places:
I agree with not duplicating data.
| - despite whitelisting, I may still want to have SA scores added
| to the header,
Ok, here's a good reason to run a whitelisted addr through SA. I
suppose this could be done by running everything through SA and
checking the whitelist separate from SA (after SA is done). You don't
_have_ to have the whitelist in SA as long as your post-SA filter
understands that. (I'm trying to find a way the desired effect can be
achieved with a minimum of code modification)
| - I find it much more predictable and easier to collect a list
| of friendly envelope sender addresses, than trying to guess for each
| mailing list in which header what address is placed. There are cases
| where some ML user names the mailing list only in Bcc, so the
| only header with a reference to ML is some List-id or such.
The List-* headers are the most reliable method of identifying a list
message. Some older lists still use X-Maililng-List, though.
| On the other hand, envelope sender address is always predictably there.
True.
| - although not currently implemented in SA, I see two uses of
| whitelists (having previous experience as a Razor-only user):
|
| * unconditionally permitting a message from whitelisted addresses,
| as is traditionally understood
|
| * turning off certain tests for certain sender addresses;
| this is typically used to turn off Razor check for popular mailing lists
| (or giving it a lower score), as Razor is more likely to produce
| false positive for such mail.
This sounds like a nice feature.
-D
--
Trust in the Lord with all your heart and lean not on your own
understanding; in all your ways acknowledge Him, and He will make your
paths straight.
Proverbs 3:5-6
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg05436/pgp00000.pgp
Description: PGP signature
