> The problem is that the script that you're using with > Communigate *assumes* that the X-Envelope headers will remain > intact, most likely because that script was written before SA > 2.50 when report_safe was introduced. > > Most mailserver configurations don't rely on message headers > to know where to deliver the message to after filtering and > therefore don't have this problem. As I mentioned in my > previous message, doing so is technically > *wrong* anyway.
So what is the proper way to do this? How do other mail servers handle it? If the resubmitted message doesn't have any envelope-to headers, how does the mailserver know who *really* to deliver it to? Do they just keep track of the message ID and don't rely on headers at all? Or should my post-processing script re-add those headers after it's been scanned?
Well the "normal" way it's done is "out of band data" in other words the actual contents of the message don't control where it is delivered to. When two SMTP servers talk to each other they exchange Envelope Sender and Envelope recipient as part of the handshake sequence - this tells the destination server who the message is for, which could be one or multiple addresses, then the data is sent, which includes the imbeded headers. The headers such as To: and From: imbeded in the actual message are _only_ there for show, they don't affect where the message goes. Thats why you can receive a message that doesn't list you in the To: header, or even have a To: header at all for that matter. This is elementary SMTP stuff.
The SMTP server knows who the recipient is even before it gets the headers or body of the message. Most mailservers remember this "Envelope-Recipient" outside of the message itself, so regardless of what processing is done to the message by "filters" (such as Spamassassin) the destination is already known beforehand.
Theres only a few that rely on sticking in extra non-standard headers, and rely on them for proper processing of messages - the only ones that spring to mind are Communigate Pro and MDaemon. Adding headers to the contents of the message and then relying on them for the final delivery of the message is a kludge, but it looks like thats the way your mailserver works.
It might be possible to work around the situation by rewriting the script that runs SA in Communigate, but so far no one has stepped up to the plate and done it...
> > Until someone comes up with a better integration script for > SA + Communigate, you'll have to use report_safe 0 mode....
Sounds like it. But report_safe 1 is so much cooler... Sad not to be able to use it.
And I agree, typically you wouldn't want a mailserver just blindly delivering to the to: and cc: addresses from the headers, but hey, that's what Communigate Pro does, but of course only via messages submitted via the PIPE interface.
In that case, the PIPE interface may be the wrong way to do it...
SMTP submitted messages of course go through all the normal checks, but PIPE must assume you've correctly formatted your message and doesn't do any anti-relay checking or the like.
And also assumes that the non-standard extra headers that its previously added are still there....
As the old saying goes, assumption is the mother of all stuffups :)
Regards, Simon
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
