I'm trying to filter messages with header Return-Path contains string '#example.eu'.
I added to /etc/mail/spamassasin/local.cf this lines:
My first attempt:
header LOCAL_DEMONSTRATION_ALL Return-Path =~ /example\.eu/i
score LOCAL_DEMONSTRATION_ALL 10.0
My second attempt:
header LOCAL_DEMONSTRATION_ALL ALL =~ /Return-Path.*example.eu>/i
score LOCAL_DEMONSTRATION_ALL 10.0
Another filters work, but this above doesn't. I checked my regex is Ok.
What's wrong? Thanks.
The Return-Path header contains the Envelope Sender and is typically added to the email when it is delivered to the recipient's mailbox, i.e. it is not present as a visible header while the email is in transit.
The Envelope Sender is passed in the SMTP dialog using the MAIL FROM command and can most often be used in SpamAssassin rules, but depending on exactly how your SpamAssassin is being called the actual details may vary.
SpamAssassin has a pseudo-header EnvelopeFrom that it tries to populate with the envelope sender using some heuristics (or you can tell SpamAssassin how it should be populated using the envelope_sender_header configuration option). For most setups a rule like this should work:
header LOCAL_DEMONSTRATION_ALL EnvelopeFrom =~ /example\.eu/i
score LOCAL_DEMONSTRATION_ALL 10.0
Related
Please, let me know whether my understanding of these things is correct:
Email-message consits of two parts: email-message envelope and contents of an email-message.
Email-message envelope is an information that is formed step by step during
SMTP-handhaking phases on a path of a message from sender's mailbox
to reciever's mailbox (during exchanging command-reply pairs between each
SMTP-client and SMTP-server on a path).
Header section is one of the two parts of a content of an email-message
(along with message body), and initially consists of the lines written by sender along with the body of the message in his email client.
Body of the email message - this thing is self-explanatory.
RFC 5322 specifies the format of the email-message content (header section and message body), and RFC 5321 specifies the work of the SMTP protocol.
Although header section of the email-message is initially formed by sender of email-message along with the body of the message (in his email-client), this header section may be further extended with some header fields containing envelope information during the path of the email-message through different SMTP-servers. For example, SMTP-server can append a new "Received:" header line to the header section. These modifications of header section must be performed according to the rules from RFC 5321 and after each of these modifications the resulting header section must me consistent with the format specified in RFC 5322.
When we open a received email-message with an email-client GUI, we see only the message body and a part of the header section of the message that was initially written by sender of email-message in his email client. But if we want to look at the full header section of the message (with those header lines containing envelope information, that were appended by SMTP servers) we can use options like "show original" in Gmail.
Since nobody answered, I will do it - I have spent some days looking for information about it, have read in RFC 5321 and RFC 5322 the most important moments and hasn't found any contradictions to the assumptions in the question.
I need to set an autoresponder that will send a message like "We got You mail! We will get back to you ASAP". The problem is that the sender of customer email is not customer itself (i.e. customer#privatemail.com), but some global mail (i.e. customerservice#marketplace.com) that contains customer private mail in the header section [Reply-to].
This is a hosted server with installed RoundCube. I can only use Sieve filters to create an autoresponder.
rule:[Autoresponder]
if allof (
header :contains "from" "#marketplace.pl",
{
vacation text:
We got You mail! We will get back to you ASAP!
.
;
}
I need to read the value of the header [Reply-To] section, set the recipient of autoresponder mail to that value and send a VACATION message. Only in Sieve language.
I am currently extending an e-mail system with an autoresponse feature. In a dark past, I've seen some awesome mail loops, and I'm now trying to avoid such a thing from happening to me.
I've looked at how other tools ('mailbot', 'vacation') are doing this, grepped my own mail archive for suspicious mail headers, but I wonder if there is something else I can add.
My process at this point:
Refuse if sender address is invalid (this should get rid of messages with <> sender)
Refuse if sender address matches one of the following:
'^root#',
'^hostmaster#',
'^postmaster#',
'^nobody#',
'^www#',
'-request#'
Refuse if one of these headers (after whitespace normalization and lowercasing) is present:
'^precedence: junk$',
'^precedence: bulk$',
'^precedence: list$',
'^list-id:',
'^content-type: multipart/report$',
'^x-autogenerated: reply$',
'^auto-submit: yes$',
'^subject: auto-response$'
Refuse if sender address was already seen by the autoresponder in the recent past.
Refuse if the sender address is my own address :)
Accept and send autoresponse, prepending Auto-response: to the subject, setting headers Precedence: bulk and Auto-Submit: yes to hopefully prevent some remote mailer from propagating the autoresponse any further.
Is there anything I'm missing?
In my research so far I've come up with these rules.
Treat inbound message as autogenerated, ignore it and blacklist the sender if...
Return-Path header is <> or missing/invalid
Auto-Submitted header is present with any value other than "no"
X-Auto-Response-Suppress header is present
In-Reply-To header is missing
Note: If I'm reading RFC3834 correctly, your own programs SHOULD set this, but so far it seems some autoresponders omit this (freshdesk.com)
When sending outbound messages, be sure to...
Set the Auto-Submitted: auto-generated header (or auto-replied as appropriate)
Set your SMTP MAIL FROM: command with the null address <>
Note some delivery services including Amazon SES will set their own value here, so this may not be feasible
Check the recipient against the blacklist built up by the inbound side and abort sending to known autoresponders
Consider sending not more than 1 message per unit time (long like 24 hours) to a given recipient
Notes on other answers and points
I think ignoring Precedence: list messages will cause false positives, at least for my app's configuration
I believe the OP's "auto-submit" rule is a typo and the official header is Auto-Submitted
References
RFC3834
This SO question about Precedence header has several good answers
Wikipedia Email Loop Article
desk.com article
Comments welcome and I'll update this answer as this is a good question and I'd like to see an authoritative answer created.
Update 2014-05-22
To find if an inbound message is an "out-of-office" or other automatic reply, we use that procedure:
First, Find if header "In-Reply-To" is present. If not, that is an auto-reply.
Else, check if 1 of these header is present:
X-Auto-Response-Suppress (any value)
Precedence (value contains bulk, or junk or list)
X-Webmin-Autoreply (value 1)
X-Autogenerated (value Reply)
X-AutoReply (value YES)
Include a phrase like "This is an automatically-generated response" in the body somewhere. If your message body is HTML (not plain text) you can use a style to make it not visible.
Check for this phrase before responding. If it exists, odds are good it's an automated response.
What is SMTP Envelope and SMTP header and what is the relationship between those? How do I extract them with Perl?
An SMTP message contains a set of headers such as From, To, CC, Subject and a whole range of other stuff.
An SMTP Envelope is simply the name given to a small set of header prefixed to the standard SMTP message when the message is moved about by the Message Transport Agent (ie. the SMTP server). The most common envelope headers are X-Sender, X-Receiver and Received.
For example Microsofts SMTP Server will add the X-Sender and a series of X-Receiver headers to the top of a message when it drops the message into its Drop folder. There will be one X-Receiver for each post box that matches the domain the Drop folder is for.
Another example is SMTP servers add a Receive: header when it receives a message from another SMTP server. This header gives various details of the exchange. Hence most emails on the tinternet once arrived at the final destination will have a series of Receive headers indicating the SMTP server hops the message took to arrive. Usually servers remove the X-Sender, X-Receiver headers when the message is finally moved to a POP3 mailbox.
Accessing Headers
On the windows platform the only way I've found to access the envelope headers is to simply open and parse the eml file. Its a pretty simple format (name: value CR LF).
Again on the windows platform the main set of message headers and body parts can be accessed using the CDOSYS.dll COM based set of objects. How you would do this on other platforms I don't know. However the header format is quite straight forward as per the envelope headers, its accessing the body parts that would require more creative coding.
The envelope is the addressing information sent to the server during the initial conversation via the "MAIL FROM:" and "RCPT TO:" commands.
The SMTP header is the collection of header lines which are sent after the DATA command is issued.
How you find them is dependant on how/where you're getting the message from, and we'd need a lot more clues to attempt to answer that.
You can actually think of three different things here. There are the directives that were exchanged between the SMTP MTAs (during each hop the message took) ... the headers that were generated by the MUA and headers that were added (or modified) by MTAs along the route that a given message traversed.
The "envelope" refers to the information provided to the MTA (normally the most recent or final destination MTA). The sender includes a set of headers after the DATA directive in the SMTP connection (separated from the body of the message by a blank line ... but double check the RFC if that's specifically supposed to be a CR/LF pair). Note that the local MTA may add additonal headers and might even modify some headers before storing or forwarding the message.
(Normally it should only add Received-by: headers).
Some MTAs are configured to add X-Envelope-To: and/or X-Envelope-From: headers. Some of them will still filter the contents of these headers (for example to prevent leakage of blind copies). (Senario: the original MUA had a BCC: line directory that a number of people be copied on the message with their names all appearing to one another in the CC: headers; for each recipient domain (MX result) the MTA will only issue RCPT TO: for only the subset of addresses for which the host if the appropriate result (its own hub, smarthost, or any valid MX for the target) --- thus any subsets of recipients who share an MX with each other would see leakage in the X-Envelope-To: headers generated by MTAs that were sloppy about the handling of this detail).
Also not that an Envelope-From line would only contain a host/domain name as supplied by the HELO FROM: or EHLO FROM: directives in the SMTP exchange. It cannot be used as a return address, for replies for example.
For Perl email related stuff have a look at the Perl Email Project.
My application uses sendmail to send outbound email. I set the 'From:' address using the following format:
Fred Dibnah <fred#dibnah.com>
I'm also setting the Reply-To and Return-Path headers using the exact same format.
This seems to work in the vast majority of cases but I have seen at least one instance in which this fails, namely when the name part of the above string contains a period (full stop):
Fred Dibnah, Inc. <fred#dibnah.com>
This fails deep inside the TMail code (I'm using Ruby) but it seems like a perfectly valid thing to do.
My question is, should I actually be setting the Return-Path and Reply-To headers using only the email address as opposed to the above Name + Email format? E.g.
fred#dibnah.com
Thanks.
In a situation like this, it is best to turn to the RFCs.
Upon reading up on your question, it appears as if You shouldn't be setting the Return-Path value ever. The final destination SMTP server is supposed to be setting this value as it transitions the message to your mailbox (http://www.faqs.org/rfcs/rfc2821.html starting at 4.4).
According to http://www.faqs.org/rfcs/rfc2822.html the Reply-To field can have the following formats
local-part "#" domain (fred#dibnah.com for example)
display-name (Fred Dibna for example)
I would recommend using option 1 as it seems to be the most basic, and you will likely have less issues with that format. In choosing option 1, your Reply-To field should look like the following:
Reply-To: fred#dibna.com