CiviCRM Community Forums (archive)

Overriding VERP - not working?

I'm checking the box to Override VERP in step 3 of CiviMail, yet the return address indicated in the reject log still says:
<myemailusername>+b.57.86.09111b0c7f406d48@<mydomain>

I thought that checking the box would allow the email address to be used as the return address?   Am I not understanding how the override VERP is supposed to work?

Thanks.  Dave

Overriding VERP - not working?

I'm checking the box to Override VERP in step 3 of CiviMail, yet the return address indicated in the reject log still says:
<myemailusername>+b.57.86.09111b0c7f406d48@<mydomain>

I thought that checking the box would allow the email address to be used as the return address?   Am I not understanding how the override VERP is supposed to work?

Ok, let me clarify this a bit.

There are two VERP-like addresses that we use in this scenario – one is the bounce address (which lets CiviMail track hard and soft bounces), the other is the reply address.

When CiviMail sends a mailing, it sets the SMTP envelope’s FROM address to the bounce VERP address – so that if there’s a hard bounce on the SMTP level, CiviMail knows who was bouncing. The SMTP envelope’s FROM address is also put in the email’s Return-Path header, and this is the address the soft bounces go to (when the SMTP transaction succeeded, but some server down the road had problems – like the mailbox being over quota or the target server being temporarily offline).

We use another VERP-like address to track bounces – this is the address that the Reply-To header is set to, and this lets CiviMail track (and forward, if so checked on the first mailing step) replies to a given mailing. The ‘Override VERP?’ checkbox is only for this address – if it’s checked, Reply-To will be set to the From email address and CiviMail won’t be able to track replies. It has nothing to do with the bounce VERP address, the SMTP envelope’s FROM address nor the Return-Path header.

Your server logs tell about the Return-Path header, not the Reply-To header that ‘Override VERP?’ concerns.

Ouch too many options. Let me try to take it from another angle.

In the doc it says that you don't have to setup a return channel, but as the return path and envelope  are always set, it means that the bounce are going to r.xxx@fixme.org (the default mailbox) ?

The message on the help is
"If this box is checked, the automatically generated VERP address in the Reply-To will be overriden by the From email address specified above. Consult with your site administrator before using this feature as it may affect handling of bounced emails and replies."

But checking it has no impact on the bounced emails, as civimail  will always use a VERP and go to the default mailbox, right ?

I think it would be useful to have an option to use civimail without return channel that works, ie.
* if the mailbox is fixme, put the from in the envelope and return-path.
* Override is checked by default (actually can be hidden)

Otherwise, I'm confused, in my postfix log I see the sender email address, not the VERP. Am I missing something ?

just ran into this issue, and agree with Denver Dave that the existing behavior is misleading (and incomplete).

we need a way to allow people to completely disable any VERP behaviors -- whether on the reply or return path. in one case I have, the organization hosts email through exchange and doesn't make use of any automated message processing actions. it appears that the VERP-created return-path may be causing a large number of emails to be flagged as spam on the receiving end, in addition to causing bounces to be lost (as they don't land in a real mailbox).

hey X+
I know we had this conversation elsewhere in the forums recently, but I think we need to have the ability to completely shut down VERP if desired. Bottom line is that some orgs don't want to handle bounces this way, and the current config forces the issue, with the only option to hack code if you want to disable.

hey X+
Bottom line is that some orgs don't want to handle bounces this way.

How do they want to handle it ?
1) The don't want to handle it. That's not good for their karma, and a sure way to get the server flagged as a spammer.

Just don't do it.

2) By using something else than VERP. The only other method I know is to put an extra X-verp type=xxx of header, and when you receive the bounce, you check for that header, so you can match the sender.

This sometimes works, but quite a few proxy/mail servers delete these extra headers when they send a bounce.

You can try reading the bounces, you'll see that quite a few don't have the needed header info, so you don't know who bounced.
Try on one of your bounce mailboxes, write a program that read the emails and tell us what % have the header.

3) Any other method I've tried sucks even more.

so a very simple use case is a small organization with a small list of contacts (let's say < 500) who simply wants all bounces returned to their primary mailbox for manual processing.

If their mailbox is ngo@example.org then make the bounces use the ngo+ localpart; this way the bounces will land in their inbox (most servers deliver ngo+b.1.2.…@example.org-bound mail to ngo@example.org by default, the rest should be configurable to do so; if not, they can use Gmail as a proxy for this).

...which naturally is what they are using (the client that prompted this discussion).

i'm still curious -- if verp is completely disabled and bounces are processed manually, how does that risk exposing the site as a perceived spammer?