What I Want
We send out bulk renewal notices via email and it would be ideal if we could link any bounce messages with the corresponding record in our database. I recently learned about VERP (wiki) and thought that would be the perfect solution for us.
What I Tried
I did a test before making any changes and the message is bounced back to sender, as expected. Then I uncommented this line in /etc/postfix/main.cf and restarted Postfix.
recipient_delimiter = +
The Problem
Unfortunately, I can't seem to get it to work. Messages sent to addresses that include the delimiter are no longer rejected, but they don't appear to be delivered anywhere either. Here's an excerpt from the maillog:
Jul 8 12:14:36 cl-t082-392cl postfix/smtpd[28723]: 6E98A1A404CC: client=mta02.eastlink.ca[24.224.136.13]
Jul 8 12:14:36 cl-t082-392cl postfix/cleanup[28727]: 6E98A1A404CC: message-id=<6.1.2.0.2.20130708131351.24958960#pop.eastlink.ca>
Jul 8 12:14:36 cl-t082-392cl postfix/qmgr[28717]: 6E98A1A404CC: from=<me#example.com>, size=1343, nrcpt=1 (queue active)
Jul 8 12:14:36 cl-t082-392cl postfix/pipe[28752]: 6E98A1A404CC: to=<bounces+test#ourdomain.com>, relay=plesk_virtual, delay=0.22, delays=0.15/0/0/0.07, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Jul 8 12:14:36 cl-t082-392cl postfix/qmgr[28717]: 6E98A1A404CC: removed
So it appears that Postifx is doing its job, but that the plesk_virtual service is dropping the ball. No message is returned to sender. No message shows up in bounces/Maildir/cur. If plesk_virtual is writing an error somewhere, I don't know where (I checked /var/log/messages).
My Search Efforts
I searched Google, here, and the Parallels forums. I got several hits in Google for the same problem I am having, but they are all for the same message which is dated almost 3 years ago. And there was no solution given. I posted to the Parallels forums several days ago. I've gotten a few views, but zero responses.
What I Don't Want
I've seen similar problems where the suggestion was to forward all undelivered mail to a particular address. That's a catch-all. And that is not a realistic solution in today's world of spam.
Question
How do I get Plesk to correctly recognize and deliver messages to addresses with the delimiter? I can't imagine that I am the only one who wants to do this on a Plesk server.
I answered this on the Plesk forums. For anyone still interested there is a postfix workaround.
Added the following to the main.cf:
recipient_canonical_classes = envelope_recipient
recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical_map
Created a file /etc/postfix/recipient_canonical_map with this regex:
/^(.+)\+.+#(.*)/ ${1}#${2}
Granted, it assumes + is the only VERP delimiter but it works. The only caveat is that it does not bounce bad addresses, which may not be a bad thing..
Related
Hello I have a google docs document where I installed a simple emailing code on as follows:
function sendMail() {
var file = DriveApp.getFileById('XXXXXXXX');
var recipients = "mymail#group1.com" + "mymail#group2.com" + "mymail#group3.com";
MailApp.sendEmail(recipients, 'Daily Notes', 'Please see file Attached.', {
name: file.getName(),
attachments: [file.getAs(MimeType.PDF)]
});
}
The code works fine it sends the email to multiple group emails which I want it to send. It has done this for a month now. But until recently, I keep receiving this Mail Delivery Subsystem after 20 minutes or 1 hour from the original email which is sent out and inside the error message email it says:
"The following addresses had permanent fatal errors"
and it points to only one of the emails I send daily mails to. It also says something like this: (reason: 554 5.4.6 Too many hops). and then this:
554 5.4.6 Too many hops 53 (50 max).
The Good Doc's file has Google's time-driven trigger as you can see in the image below. I wonder if somehow the trigger is running twice in the time interval I gave to it. Could it be why this is happening?
In almost all cases 554 5.4.6 Too many hops 53 (50 max) means loop along email delivery path e.g. server A forwards to server B, server B forwards to server A, server A forwards to sever B, …. It is detected by counting Received: headers in message passing via give SMTP/email server.
Suggested fixing procedure:
Inspect Reveived: headers in email bounce message to locate server(s) responsible for the loop.
contact the relevant postmaster
In many years I have seen just one "real life" case when bounce message/email like that was not caused by email delivery loop.
There is a problem accessing the To alias from a o365 account IF the from account is also o365. If the from account is say, gmail, it works.
If I send an email to alias#mycompany.com which is an alias to realAccount#mycompany.com, if I examine the To header in Outlook, it will always show me the original alias. If I view the header progrmatically, it will NOT show the alias if it was sent from an o365 account. Instead, it shows the real account. If I do this same test with a gmail instead of an o365 email it works -- shows the alias in the To: header as expected.
How does Outlook access this data? The number of headers are different too. Outlook contains more data. Has anyone experienced this? Any ideas on how to access the alias like Outlook does?
Header when accessing from Outlook:
From: o365Account#somecompany.com
To: ***************** alias#mycompany.com ****************
Subject: shdaKJSDHA
Thread-Topic: shdaKJSDHA
Thread-Index: AQHUSTkz1fQhzI5SG0ie26mNIvHmmQ==
Date: Mon, 10 Sep 2018 19:05:12 +0000
Message-ID: <---#-----.prod.outlook.com>
Header when accessed programatically:
From: o365Account#company.com
To: *****************realAccount#mycompany.com ****************
Subject: shdaKJSDHA
Thread-Topic: shdaKJSDHA
Thread-Index: AQHUSTkz1fQhzI5SG0ie26mNIvHmmQ==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 10 Sep 2018 19:05:12 +0000
Message-ID: <----#-----.prod.outlook.com>
Keep in mind that Exchange always resolves the sender and recipients to their primary addresses both when sending and when receiving the messages. This is just the way it works.
Are you sending through SMTP?
You know what I ended up doing? I made a Distro list with 1 recipient. The distro list takes the place of the alias. It always shows the To: as the distro list. That way it doesn't get lost. Thank you for helping me understand Exchange Server dmitry-streblechenko.
Somebody in my company is being subject to phishing. My first suggestion was just to change the password. However after awhile I received a fake mail from her address again.
Looking at the raw source of the email I found that there is another person's email in X-Sender-ID and I'm wondering who that might be. Is that the person who sent the email or can it be an account that has been hijacked? (I replaced the email with "somebody#host.com")
X-Virus-Scanned: OK
Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: somebody-AT-host.com) with ESMTPA id DF2788019C;
Fri, 21 Nov 2014 07:54:42 -0500 (EST)
X-Sender-Id: somebody#host.com
Received: from smtp.emailsrvr.com ([UNAVAILABLE]. [2.133.148.211])
by 0.0.0.0:587 (trex/5.3.2);
Fri, 21 Nov 2014 12:54:46 GMT
What is X-Sender-ID? And what is the email it contains?
My deliberations are based on this RFC which describes the Privacy Enhancement for Emails which you are obviously using.
Basically it says about the X-Sender-ID:
[...] encapsulated header field, required for all
privacy-enhanced messages, identifies a message's sender and provides
the sender's IK identification component.
What does this mean?
First of all you have to check if the mail is properly signed. If thats the case you can be sure that somebody#host.com has a certificate. And you can be sure that the mail you received has been sent from this mail address.
I can't tell you the consequences which result out of this fact as I don't know how your company is deploying the certificates etc. ... the mail address/certificate could also have been hacked and thereby abused.
I hope this helps you for your further research.
While #LMF's answer is useful technical information, I'd like to offer a possible alternative explanation.
Spammers who are not familiar with e-mail (and PHP programmers with no other malicious intent) tend to succumb to cargo cult programming when it comes to email headers. In other words, if there is something they don't understand, they might think it does something useful, and include it in their message template.
Without knowledge about your email infrastructure, or other messages of yours to compare to, I would simply assume everything below the top-most Received: header is forged, and basically without meaning.
If you have a system which runs something called trex (maybe this one?) and it really manages to write a Received: header like that, I might be wrong. The format needlessly deviates from the de-facto standard Sendmail template in a few places, but it's not technically wrong (the format is basically free-form, but introducing ad-hoc syntax makes it harder to guess what the fields mean).
Again, more information about what your typical email (and your correspondent's typical mail) looks like, this is heavy on speculation.
The x-sender-id, along with the x-recipient-id are used to specify which interchange key was used in the broadcast of the message.
X-Sender-ID entity_id : issuing_authority : version
X-Recipient-ID entity_id : issuing_authority : version
The first field contains the identity of the sender or receiver. The first field is mandatory, must be unique, and must be formatted as user#host whereas the host is a fully qualified host address.
The second identifies the name of the authority which issued the interchange key.
The third field specifies the specific type of interchange key which was used. This is represented by an alphanumeric string defined by the issuing authority to label and organize the numerous interchange keys issued by that authority. It is recommmended that they use a timestamp but is not always the case.
If the field values of the x-sender-id second and third field are identical to that of the x-recipient-id they may be only listed in the field which is defined last.
Further Reading
"Distributed Computing & Cryptography: Proceedings of a DIMACS Workshop"
This is one of those hard to explain questions. I've tried my best below, hopefully it is clear what I mean.
Emails are coming in to an address (foo#example.com), and are being forwarded to another email address (bar#subdomain.example.com). The second email address further pipes the email to a simple script, but the script needs to actually know the second email address as it provides meta-data that is crucial to sorting the message (that is, the script gets piped any email sent to *#subdomain.example.com, and it needs to see that it got forwarded to bar#subdomain.example.com in order to correctly process the incoming message).
Originally, I thought that the virtual alias used to forward messages from foo#example.com to bar#subdomain.example.com would update the envelope-to header, but it remains unchanged the same. None of the other headers nor the "received" line reflect that the message was forwarded. My theory is that maybe the pipe instructions for *#subdomain.example.com can be updated to somehow pass the actual address on to the script, but I am not sure how.
For reference, I have included a few examples below:
Headers, after being forwarded:
From sender#example.com Sun Dec 11 19:53:40 2011
Envelope-to: foo#example.com
Received: ...
Subject: Test 6
The valias file for subdomain.example.com (/etc/valiases/subdomain.example.com):
*: "|/home/user/example_script.x.php"
And I answered my own question. It turns out, the recipient is accessible in an environment variable. In my case, since I am using PHP, I can just use the following variable:
$_ENV['RECIPIENT']
I'm trying to sort out an opt in mailing list system. I understand the basic principles and design required but i'm having an issue with it being picked up as spam.
If i send a html email through outlook through email#domain.com it works fine and is not treated as spam. When i use the Zend_mail object to send mail it sends but is treated as spam on the test emails accounts i'm sending it too.
This is the code im using to send an email item.
//send an email
$mail = new Zend_Mail();
$config = array('auth' => 'login','username' => 'email#domain.com','password' => 'mypassword');
$transport = new Zend_Mail_Transport_Smtp('mail.domain.com', $config);
$mail->setSubject($item->title);
$mail->setFrom("email#domain.com");
$mail->addTo($item->email, $item->forename);
//$mail->setBodyText($item->contentPlain);
$mail->setBodyHtml($item->contentHTML);
$mail->send($transport);
As you can see im using the smtp transport object to authenticate but it still seems to treat this as spam. Anyone with pointers or tips is very much appreciated!!
Header info from the email that is treated as spam:
It seems to contain a couple of client domain names in the header info that i host for people any ideas why that would be the case? I use a shared IP address with about 10 domains on it
Received: (qmail 1436 invoked from network); 14 Aug 2009 16:02:10 +0100
Received: from clientdomain1.co.uk (HELO localhost) (91.192.***.196)
by clientdomain2.info with SMTP; 14 Aug 2009 16:02:10 +0100
Subject: Manchester 2 Day Seminar: Dealing with difficult people
From: events#domain.com
To: Andi <subscriber1#domain.com>
Date: Fri, 14 Aug 2009 15:02:10 +0000
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
"Roll your own mail" is often treated as spam by large hosted email systems. When you use a paid service to send out mass emails, you are paying for those company's agreements with the major email vendors to keep them white-listed.
One thing you can do, though, is to ensure that the account you are sending from exists and the email is being sent from a matching domain (e.g. #foo.com sent from foo.com's smtp server). That is a big red flag for spam filters.
Compare your email and email from outlook. Are any headers missing? Which? Do they seem significant?
Try this to get rid of the last localhost reference:
$protocol = new Zend_Mail_Protocol_Smtp('localhost');
$protocol->connect();
$protocol->helo('mail.yourserver.com'); //**DO THIS**
$transport->setConnection($protocol);