Return-Path of bounced messages

[web12]

Hi

Seem to be having a problem here that one of my clients has reported where one of their email accounts is over quota and the bounce-back messages are not going back to the original sender, but rather are ending up in the main email account for the recipients domain, ie the default email account.

This is happening for mail originating from outside servers as well as local-domains.

I have checked this and can confirm that its happening, but cant fathom whats causing it.

I have "Discard emails for users who have exceeded their quota instead of keeping them in the queue." checked, and there certainly arent bounce messages turning up in the queue.

Can anyone explain this and what can be done to correct it?

tia

[chirpy]

That setting is for email sent to account, not for bounces. The solution is to keep the account under quota. Such are the consequences of ignoring the over quota emails.

[web12]

That setting is for email sent to account, not for bounces. The solution is to keep the account under quota. Such are the consequences of ignoring the over quota emails.

Hi Chirpy

Was hoping you would post as you seem to be the exim king around here.

The actual account is under quota, but the email address is over quota.

Ive actually recently figured out that this is completely unique to this domain. Trying it on other domains on the same server produce a bounce message when the email account goes over.

But, the account mentioned in the first post bounces the messages to the main email account for the domain.

Cant seem to find any strange forwarding going on, so not sure really whats happening.

[web12]

This is strange

I just sent a test email to a test account created under this misbehaving domain and checked the headers and it indeed seems to be forwarding on all mail from the main account.

So, say the account username is account123, the headers for the mail sent to an account under this domain read as follows:-

From account123@server.name.net Fri May 06 16:46:18 2005
Return-path: <account123@server.name.et>
Envelope-to: testaccount@domain.com

So for some reason all email is being piped through the main email account for this domain, to the individual email accounts. This appears to work fine normally, apart from all bounces are going back to the account123 email address instead of to the actual real sender.

[chirpy]

Have a check of /etc/valiases/domain.net, also what does it have set for the Default Address on the domain (*: entry in valiases)?

/scripts/mailperm is always worth a try too.

[web12]

Ran /scripts/mailperm but without any change in behaviour.

In /etc/valiases/domain.net is the following:-

user1@domain.net: user1@anotherdomain.net
user2@domain.net: user2@somewhereelse.com
*: user3@domain.net

Nothing unusual there, right?

[chirpy]

It does seem right. It may just be a quirk of the way cPanel have setup virtual email accounts - I guess the important thing is to educate users to keep below their account limits and not to use the "leave mail on the server" option in their email client, which they really shouldn't use anyway, for that the should use IMAP access.

[web12]

ok

figured something else out with this.

If I disable spamassasin for that user then it functions correctly, ie, the mail that takes the account over quota gets bounced back to the original sender.

Whats the cause of this? is it a problem with setup?

Cheers

[web12]

This is definitely a problem which I can confirm on a seperate server... wondered if someone else can confirm also please?

Steps to reproduce:-

1/ Create a test email account on a domain with just 1mb storage

2/ Send an email to that test account with an attachment larger than 1mb

3/ Mail should get returned back to the sender with a mailbox full message

4/ Go to the test account and enable spamassasin for that domain

5/ Re-Send the email with the > 1mb file attachment

6/ Bounce message is not received, it is, in fact, sent to username@domain.com (the main email account for the domain).

Wondering if this is worthy of a bugzilla entry or not?

[chirpy]

That certainly looks worthy of a bugzilla entry if you can recreate it so clearly.