Re: Finding the envelope-sender after always_bcc? (SOLVED)

[Jeff Weinberger]

On Jan 1, 2009, at 12:58 PM, mouss wrote:


Jeff Weinberger a écrit :


I've been reading the dspam docs this morning and the project owner
states fairly strongly that sendmail is far preferable to SMTP
re-injection (in the postfix setup docs), but doesn't say why.


if he doesn't say why, then we don't know whether there was a  
problem at
the time or if there is another reason. People have been using smtp  
mode

without problems.


I don't
know enough about the workings of dspam (yet) to know, but I'd tend  
to

agree with you on the use of SMTP as more desirable.

dspam has always had this mysql issue, which is related to its  
database

of spam tokens, and I'll look into whether it might be related.



I don't think it is related, but check it though...



First let me thank mouss for all his generous help on this - as it  
turned out, I was able to solve it with the information in this thread  
and http://www.pubbs.net/postfix/200811/3719/ from Victor but it  
required some trickery to get the envelope-sender past dspam.


I'm posting my solution here in the hope that it might help someone  
else.


I used a pcre: table for smtpd_sender_restrictions and the PREPEND  
action as follows:


main.cf:
 smtpd_sender_restrictions = check_sender_access pcre:/etc/ 
postfix/smtpd_sender_restrictions.pcre


smtpd_sender_restrictions.pcre
/^(.*)/  PREPEND X-Envelope-Sender: ${1}

this will insert into every message a header "X-Envelope-Sender: "  
followed  by the envelope sender value. It won't pass the envelope- 
sender as SMTP MAIL FROM (dspam wasn't designed to do that, and until  
I take the step to a better before-queue filter or something that  
does, this will work, since all I needed was to capture the envelope- 
sender).


Limited testing shows this to work. There might be cases beyond what I  
tested that will behave differently than I expect or very oddly.


Thanks again!

Re: rate limit outgoing mails with mailman

[Victor Duchovni]

On Thu, Jan 01, 2009 at 11:04:50PM -0500, ja...@monsterjam.org wrote:

> hey folks.. Im running the latest postfix on an ubuntu server with
> mailmain for mailing list management.. everything is pretty much working
> fine except that Im trying to get some kind of rate-limiting or
> throttling working for all outbound messages. Ive searched all over and
> found the smtpd -D and debugger_command = sleep 8
> but for some reason, this doesnt seem to work for mails sent out via a 
> mailing list with
> mailman.. I see emails getting relayed to my isp's smtp server one right
> after the other. Other settings I have been fooling with (in main.cf)
> are
> initial_destination_concurrency = 1
> default_destination_recipient_limit = 1
> default_destination_concurrency_limit = 1
> smtp_destination_concurrency_limit = 1

When you set the recipient limit to 1, concurrency is measured per
recipient, not per-nexthop. The solution is to not set the recipient
limit to 1. It is unlikely the ISP objects to say 10 (or even the
RFC required 100) recipients per delivery.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: rate limit outgoing mails with mailman

[Terry Carmen]

ja...@monsterjam.org wrote:

I want only 1 smtp connection at a time to be made out from my server to
my ISP's server.. Can someone please help me with a config that will
accomplish this?
  
If your ISP doesn't want to handle your list traffic, trying to get 
around their restrictions isn't going to make them happy.


However if you really want to do this, you can set maxproc to 1 for smtp 
in master.cf.


Terry

rate limit outgoing mails with mailman

[jason]

hey folks.. Im running the latest postfix on an ubuntu server with
mailmain for mailing list management.. everything is pretty much working
fine except that Im trying to get some kind of rate-limiting or
throttling working for all outbound messages. Ive searched all over and
found the smtpd -D and debugger_command = sleep 8
but for some reason, this doesnt seem to work for mails sent out via a 
mailing list with
mailman.. I see emails getting relayed to my isp's smtp server one right
after the other. Other settings I have been fooling with (in main.cf)
are
initial_destination_concurrency = 1
default_destination_recipient_limit = 1
default_destination_concurrency_limit = 1
smtp_destination_concurrency_limit = 1

I want only 1 smtp connection at a time to be made out from my server to
my ISP's server.. Can someone please help me with a config that will
accomplish this?

regards,
Jason

Re: issue connecting to mysql after upgrade

[Terry Carmen]

Terry Carmen wrote:



Jeff Weinberger wrote:

Hello again:

One more issue on which I would appreciate any help anyone can offer:

Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and 
my MySQL installation from 5.0.51b to 5.0.75. Immediately after 
restarting everything (the whole computer), I started seeing these 
messages in my mail log:


 Jan  1 09:48:35 s postfix/smtpd[13199]: warning: connect to 
mysql server localhost: Can't connect to local MySQL server through 
socket '/tmp' (38)
 Jan  1 09:48:35 s postfix/cleanup[13201]: warning: connect to 
mysql server localhost: Can't connect to local MySQL server through 
socket '/tmp' (38)
 Jan  1 09:48:42 s postfix/trivial-rewrite[13205]: warning: 
connect to mysql server localhost: Can't connect to local MySQL 
server through socket '/tmp'



(38)Can't connect to local MySQL server through socket '/tmp'

/tmp isn't a socket, it's a directory.

Run:

mysql --xml -uroot -p -e "SHOW VARIABLES WHERE Variable_name = 'socket';"

to see where mysql has it's socket, then make sure that postfix is 
looking for it there, or move the socket, or switch postfix and MySQL 
to use a TCP socket.


If you're running chroot'ed the socket needs to be where postfix can 
find it.


Terry


Sorry about the --xml. Although it doesn't hurt anything, you don't 
really need it.


In any event, if you're getting the error messages, I don't see how 
postfix can be using mysql.


Terry

Re: issue connecting to mysql after upgrade

[Jeff Weinberger]

On Jan 1, 2009, at 4:53 PM, mouss wrote:


Jeff Weinberger a écrit :

[snip]

- try with "hosts = 127.0.0.1" (without "localhost")


Tried this - no change. :(



ahem. if you do this, you should not hear about a socket. it should  
use

a TCP connection. can you show the errors?


I would think so also.

I'm at a loss here, but I think this is no longer a problem. i was  
able to turn on very verbose logging in mysql, and it turns out that  
all the queries are in fact being made.


I also have to confess to a bit of stupidity about my own ability to  
hold enough configuration information in my head (making postfix much  
smarter than I am!). I have dspam set to filter all mail both inbound  
and outbound (this has to change, but served the purpose when I  
initially set it up. And to stop multiply always_bcc results,  
specified "-o receive_override_options=no_address_mappings" in the  
master.cf entry for re-injection. the pipe to dspam is case-folding  
and then the sender_canonical_maps are being ignored. I didn't event  
think to look at this as a reason canonical was failing.


I apologize sincerely for taking so much time and effort to get here  
and for leading you down this path. But still I appreciate the help.  
This will help me clean up this set of configuration issues.


As to the warnings, I still don't know. Everything seems to be  
working, but issuing warnings.


Here are a bunch of the errors - from more reading I think the key is  
in the (38) which I think(??) is a postfix error code...is it? do you  
know what it means?:


Jan  1 17:00:33 s postfix/smtpd[21502]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:00:33 s postfix/cleanup[21517]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:06:33 s postfix/trivial-rewrite[21546]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
Jan  1 17:06:34 s postfix/smtpd[21544]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:06:34 s postfix/cleanup[21547]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:09:42 s postfix/trivial-rewrite[21582]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
Jan  1 17:09:42 s postfix/smtpd[21581]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:09:42 s postfix/cleanup[21583]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:09:45 s postfix/local[21587]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:09:58 s postfix/trivial-rewrite[21592]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
Jan  1 17:11:50 s postfix/trivial-rewrite[21624]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
Jan  1 17:11:50 s postfix/smtpd[21623]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:11:50 s postfix/cleanup[21625]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:15:46 s postfix/trivial-rewrite[21648]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
Jan  1 17:15:49 s postfix/smtpd[21646]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:15:49 s postfix/cleanup[21649]: warning: connect to mysql  
server localhost: Can't connect to local MySQL server through socket '/ 
tmp' (38)
Jan  1 17:19:10 s postfix/trivial-rewrite[21675]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)






[snip]


why do use sender_canonical instead of canonical? rewrite should be
consistent, and "your sender is the recipient's recipient"...





This is mostly because I use maildrop as the virtual delivery agent  
for
many of the virtual mailboxes. I'm really just testing this, and  
may end

up using canonical instead. But here's my thinking:

I have one user who wants a minor change - sounds silly, but gives  
me a

good chance to experiment/learn. I'm rewriting the one address to a
specific capitalization. I know I'll be doing more with more users  
soon.


I want to rewrite when mail goes to someone outside my postfix  
install.
canonical_maps would also rewrite inbound mail to that address,  
which is

not bad, but not the desired behavior.

So I am trying sender_can

Re: issue connecting to mysql after upgrade

[mouss]

Jeff Weinberger a écrit :
>> [snip]
>>
>> - try with "hosts = 127.0.0.1" (without "localhost")
> 
> Tried this - no change. :(
> 

ahem. if you do this, you should not hear about a socket. it should use
a TCP connection. can you show the errors?

> [snip]
>>
>> why do use sender_canonical instead of canonical? rewrite should be
>> consistent, and "your sender is the recipient's recipient"...
>>
>>
>>
> 
> This is mostly because I use maildrop as the virtual delivery agent for
> many of the virtual mailboxes. I'm really just testing this, and may end
> up using canonical instead. But here's my thinking:
> 
> I have one user who wants a minor change - sounds silly, but gives me a
> good chance to experiment/learn. I'm rewriting the one address to a
> specific capitalization. I know I'll be doing more with more users soon.
> 
> I want to rewrite when mail goes to someone outside my postfix install.
> canonical_maps would also rewrite inbound mail to that address, which is
> not bad, but not the desired behavior.
> 
> So I am trying sender_canonical_maps to get the behavior I want.
> 

Then you may want to use smtp_generic_maps instead of canonical.

Re: Rejecting emails with invalid/unlikely dates?

[IBBoard]

There are some very definite patterns in the dates of the spam I'm 
getting (xx/xx/3609 and 19 Jan 38) so a modification of those regex's 
should do the trick for now.


As for SpamAssassin, I don't use it at the moment. I'm running a small 
VPS with 128MB of memory and a handful of email accounts. My recent 
tally of spam has been about half-a-dozen per day at most, and the 
majority of those were cut by checking SPF records to stop emails that 
pretend to be from me.


Presumably there is some way of parsing the various formats of date used 
in email headers, otherwise email clients couldn't display it. If anyone 
knows of or could create a script that could do a more generic job (such 
as the 14 day window I mentioned earlier) then that'd be great.


Thanks,

IBBoard


Noel Jones wrote:

mouss wrote:

Darren Pilgrim a écrit :

IBBoard wrote:

I've been looking around but so far haven't been able to find anything
(partly because it's difficult to phrase a search query!). If someone
has a solution/config for this then that'd be great.

Before anyone points out issues with GMail and lack of control, this
is all being done on a domain on a VPS. I'm just using my Gmail
address for the mailing list :)

Basically, 99% of the spam I get (which is only a small amount
compared to some people) is either a) purporting to be from me, to me
or b) has a date that Thunderbird reports as 1976 or 2038 (but is
really 3609 or just "38"). I've resolved the first part with SPF
records and checking them in Postfix, but I can't work out how to get
Postfix to reject mail that is outside a 14 day window from today (or
silently dispose of it if it's not possible because it has to get too
far in to the system to fail it).
You need a content filter for this. 


and to reject, he needs to run it in pre-queue mode (proxy_filter). or
he could use a milter such as milter-regex.


Header checks can do this; however,
they're static, so you have the problem of updating them constantly to
keep the validity window moving. 


He can use a cron to update the header_checks daily. This is "simpler"
than milter/proxy_filter.


Plus there's the issue of date
formats. 


This is not a problem here, since he wants to block "known" spam. so he
can write expressions for that spam. and if he only wants to block on
the year, then it's even easier.


The best way, IMO, is a policy service that can grok a wide
variety of date formats and check if the date is within 14 days of the
current time.



a policy service doesn't see headers. a milter or a proxy_filter does.


There are spamassassin rules for future dates in message headers, so you
might try that route instead of rolling your own.


this is indeed easier and maybe safer (well, if OP uses spamassassin).


Once upon a time, these pcre header_checks were posted to this list:
(beware line wrapping; each of these are a single line)

### Date checks
IF /^Date:/
/Date:.*([3-9].:..:|2[4-9]:..:|:[6-9].:|:..:6[0-9])/
HOLD invalid time in Date header

/ \d\d:\d\d:\d\d [^+-][2-9][5-9][0-9][0-9]\s*$/  HOLD invalid time zone 
offset in Date header



/^Date: .* 19[0-9][0-9]/   HOLD UBE Header - Past Date #1
/^Date: .* 200[0-6]/   HOLD UBE Header - Past Date #2

/^Date:.*((3[2-9]|[4-9][0-9]) Jan|[3-9][0-9] Feb|(3[2-9]|[4-9][0-9]) 
Mar|(3[1-9]|[4-9][0-9]) Apr|(3[2-9]|[4-9][0-9]) May|(3[
1-9]|[4-9][0-9]) Jun|(3[2-9]|[4-9][0-9]) Jul|(3[2-9]|[4-9][0-9]) 
Aug|(3[1-9]|[4-9][0-9]) Sep|(3[2-9]|[4-9][0-9]) Oct|(3[1-9]
|[4-9][0-9]) Nov|(3[2-9]|[4-9][0-9]) Dec)/   HOLD Invalid date header. 
Correct your clock and resend please.


/^Date:.*(2[4-9]:[0-9]{2}:[0-9]{2}|[3-9][0-9]:[0-9]{2}:[0-9]{2}|[0-9]{1,2}:[6-9][0-9]:[0-9]{2}|[0-9]{1,2}:[0-9]{2}:(6[2-9]|[ 

7-9][0-9]))/   HOLD Invalid time header. Correct your clock and resend 
please.


ENDIF
### END DATE CHECKS

I have these set to HOLD since they rarely catch anything other than the 
occasional legit mail with a bad year.  YMMV.

Re: issue connecting to mysql after upgrade

[Jeff Weinberger]

On Jan 1, 2009, at 1:55 PM, mouss wrote:


Jeff Weinberger a écrit :

Hello again:

One more issue on which I would appreciate any help anyone can offer:

Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5  
and my
MySQL installation from 5.0.51b to 5.0.75. Immediately after  
restarting
everything (the whole computer), I started seeing these messages in  
my

mail log:

Jan  1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql
server localhost: Can't connect to local MySQL server through socket
'/tmp' (38)
Jan  1 09:48:35 s postfix/cleanup[13201]: warning: connect to  
mysql

server localhost: Can't connect to local MySQL server through socket
'/tmp' (38)
Jan  1 09:48:42 s postfix/trivial-rewrite[13205]: warning:  
connect
to mysql server localhost: Can't connect to local MySQL server  
through

socket '/tmp' (38)

As far as I can tell this has been consistent with smtpd, cleanup and
trivial-rewrite, but nothing else. (there have been pre-existing  
issues,

per my prior conversation with mouss, with dspam, but these have not
changed at all - they existed before the upgrade and still exist)

I use mysql for nearly all my tables in postfix. All of my aliases  
are

working and forwarding fine, which means that postfix can access my
mysql database (and yes, postconf -m shows mysql). virtual is finding
the maildirs correctly for my virtual mailboxes.

However, my sender_canonical_maps are no longer working after the
upgrade (outbound addresses are not being rewritten at all as they  
were

before the upgrade)

As an example, my main.cf contains:
  sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf

and mysql_canonical_maps.cf contains:

   user = postfixuser
   password = postfixpassword
   hosts = localhost, 127.0.0.1
   dbname = postfixdatabase
   query = SELECT result FROM canonical WHERE address='%s' AND  
active='Y'


(obvious information changed). This is unchanged before and after the
upgrade.

The query works on all the addresses (I tested it at the mysql  
command

prompt).

I also tested a local telnet to 127.0.0.1 on port 3306 which worked  
as
expected and mysql responds perfectly. I also tested connection  
through
the localhost socket with works as expected. Also several other  
parts of
my mail system (e.g. courier_auth) connect through the socket and  
report

success. And as noted, postfix is able to connect most of the time
(aliases, virtual maildirs, etc.). Other software on my system, e.g.
PHP, is also able to connect to mysql successfully.

I tried all the steps in the MySQL documentation on dev.mysql.com
suggested to diagnose this error, and all confirmed that the MySQL
server is working correctly.

So I find myself not knowing where to look next, and I hope someone  
here

knows what might be happening or at least be able to point me in the
right direction.

One additional piece of information: I am running on Mac OS/X and as
part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus
needing to restart my computer). This upgrade is known to break  
postfix.

So I reinstalled postfix and my main.cf and master.cf files after the
upgrade and stopped and restarted postfix to be sure. (and mysql)

What other information might be helpful in diagnosing this?




- check whether any services are chrooted in master.cf (the 5th field
must be set to 'n' and not to 'y' or '-')?


All chroot flags are set to "n"



- try using proxymap (foo_maps=proxy:mysql:/etc/).


Tried this...no change :(




- make sure the mysql socket is accessible by postfix (and not just by
root).


I checked looking at permissions and trying it as the postfix user and  
all works (I suspected it would, as many accesses work fine (aliases,  
etc. as I noted earlier)





- try with "hosts = 127.0.0.1" (without "localhost")


Tried this - no change. :(

I tried each of the suggestions you made with alias, virtual and local  
addresses


I noticed that when local complained about mysql access, it still did  
fine looking up the local alias and forwarding it correctly.


I'm starting to wonder whether this is a "can't connect" or a delay in  
connecting - is it possible that it's taking too long to connect so a  
warning is reported, but the connection happens eventually? or that it  
works on a retry?


The only thing I've found that doesn't work as expected is  
sender_canonical_maps which would invalidate this theory, but the  
local behavior makes me think it's a possibility?


Alternatively, is it possible that something in the mysql capabilities  
of postfix compiled wrong? I am not that familiar with gcc and the  
build process (I use what I know works) - is there something I can  
look at in the ./configure or make output that would tell me?


I did try rebuilding (./configure,. make, make install) three times...




why do use sender_canonical instead of canonical? rewrite should be
consistent, and "your sender is the recipient's recipient"...





This i

Re: issue connecting to mysql after upgrade

[Terry Carmen]

Jeff Weinberger wrote:

Hello again:

One more issue on which I would appreciate any help anyone can offer:

Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and 
my MySQL installation from 5.0.51b to 5.0.75. Immediately after 
restarting everything (the whole computer), I started seeing these 
messages in my mail log:


 Jan  1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql 
server localhost: Can't connect to local MySQL server through socket 
'/tmp' (38)
 Jan  1 09:48:35 s postfix/cleanup[13201]: warning: connect to 
mysql server localhost: Can't connect to local MySQL server through 
socket '/tmp' (38)
 Jan  1 09:48:42 s postfix/trivial-rewrite[13205]: warning: 
connect to mysql server localhost: Can't connect to local MySQL server 
through socket '/tmp'



(38)Can't connect to local MySQL server through socket '/tmp'

/tmp isn't a socket, it's a directory.

Run:

mysql --xml -uroot -p -e "SHOW VARIABLES WHERE Variable_name = 'socket';"

to see where mysql has it's socket, then make sure that postfix is 
looking for it there, or move the socket, or switch postfix and MySQL to 
use a TCP socket.


If you're running chroot'ed the socket needs to be where postfix can 
find it.


Terry

Re: issue connecting to mysql after upgrade

[Muhammed Sameer]

Salaam,

I think that you may have to add proxy to this line

This is your line:
sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf

This is what I suggest:
sender_canonical_maps= proxy:mysql:/etc/postfix/mysql_canonical_maps.cf

We use postgres in our organization and we use that proxy keyword too.

Wa Salaam,
Muhammed Sameer


--- On Thu, 1/1/09, Jeff Weinberger  wrote:

> From: Jeff Weinberger 
> Subject: issue connecting to mysql after upgrade
> To: post...@yahoogroups.com, postfix-us...@yahoogroups.com, 
> postfix-users@postfix.org, postfix-us...@egroups.com
> Date: Thursday, January 1, 2009, 4:31 PM
> Hello again:
> 
> One more issue on which I would appreciate any help anyone
> can offer:
> 
> Yesterday I upgraded my postfix installation from 2.5.2 to
> 2.5.5 and my MySQL installation from 5.0.51b to 5.0.75.
> Immediately after restarting everything (the whole
> computer), I started seeing these messages in my mail log:
> 
>  Jan  1 09:48:35 s postfix/smtpd[13199]: warning:
> connect to mysql server localhost: Can't connect to
> local MySQL server through socket '/tmp' (38)
>  Jan  1 09:48:35 s postfix/cleanup[13201]: warning:
> connect to mysql server localhost: Can't connect to
> local MySQL server through socket '/tmp' (38)
>  Jan  1 09:48:42 s postfix/trivial-rewrite[13205]:
> warning: connect to mysql server localhost: Can't
> connect to local MySQL server through socket '/tmp'
> (38)
> 
> As far as I can tell this has been consistent with smtpd,
> cleanup and trivial-rewrite, but nothing else. (there have
> been pre-existing issues, per my prior conversation with
> mouss, with dspam, but these have not changed at all - they
> existed before the upgrade and still exist)
> 
> I use mysql for nearly all my tables in postfix. All of my
> aliases are working and forwarding fine, which means that
> postfix can access my mysql database (and yes, postconf -m
> shows mysql). virtual is finding the maildirs correctly for
> my virtual mailboxes.
> 
> However, my sender_canonical_maps are no longer working
> after the upgrade (outbound addresses are not being
> rewritten at all as they were before the upgrade)
> 
> As an example, my main.cf contains:
>   
> sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf
> 
> and mysql_canonical_maps.cf contains:
> 
> user = postfixuser
> password = postfixpassword
> hosts = localhost, 127.0.0.1
> dbname = postfixdatabase
> query = SELECT result FROM canonical WHERE
> address='%s' AND active='Y'
> 
> (obvious information changed). This is unchanged before and
> after the upgrade.
> 
> The query works on all the addresses (I tested it at the
> mysql command prompt).
> 
> I also tested a local telnet to 127.0.0.1 on port 3306
> which worked as expected and mysql responds perfectly. I
> also tested connection through the localhost socket with
> works as expected. Also several other parts of my mail
> system (e.g. courier_auth) connect through the socket and
> report success. And as noted, postfix is able to connect
> most of the time (aliases, virtual maildirs, etc.). Other
> software on my system, e.g. PHP, is also able to connect to
> mysql successfully.
> 
> I tried all the steps in the MySQL documentation on
> dev.mysql.com suggested to diagnose this error, and all
> confirmed that the MySQL server is working correctly.
> 
> So I find myself not knowing where to look next, and I hope
> someone here knows what might be happening or at least be
> able to point me in the right direction.
> 
> One additional piece of information: I am running on Mac
> OS/X and as part of this upgrade, I installed the 10.5.5 to
> 10.5.6 upgrade (thus needing to restart my computer). This
> upgrade is known to break postfix. So I reinstalled postfix
> and my main.cf and master.cf files after the upgrade and
> stopped and restarted postfix to be sure. (and mysql)
> 
> What other information might be helpful in diagnosing this?
> 
> Thank you for any help you can offer!


  

Re: issue connecting to mysql after upgrade

[mouss]

Jeff Weinberger a écrit :
> Hello again:
> 
> One more issue on which I would appreciate any help anyone can offer:
> 
> Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and my
> MySQL installation from 5.0.51b to 5.0.75. Immediately after restarting
> everything (the whole computer), I started seeing these messages in my
> mail log:
> 
>  Jan  1 09:48:35 s postfix/smtpd[13199]: warning: connect to mysql
> server localhost: Can't connect to local MySQL server through socket
> '/tmp' (38)
>  Jan  1 09:48:35 s postfix/cleanup[13201]: warning: connect to mysql
> server localhost: Can't connect to local MySQL server through socket
> '/tmp' (38)
>  Jan  1 09:48:42 s postfix/trivial-rewrite[13205]: warning: connect
> to mysql server localhost: Can't connect to local MySQL server through
> socket '/tmp' (38)
> 
> As far as I can tell this has been consistent with smtpd, cleanup and
> trivial-rewrite, but nothing else. (there have been pre-existing issues,
> per my prior conversation with mouss, with dspam, but these have not
> changed at all - they existed before the upgrade and still exist)
> 
> I use mysql for nearly all my tables in postfix. All of my aliases are
> working and forwarding fine, which means that postfix can access my
> mysql database (and yes, postconf -m shows mysql). virtual is finding
> the maildirs correctly for my virtual mailboxes.
> 
> However, my sender_canonical_maps are no longer working after the
> upgrade (outbound addresses are not being rewritten at all as they were
> before the upgrade)
> 
> As an example, my main.cf contains:
>sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf
> 
> and mysql_canonical_maps.cf contains:
> 
> user = postfixuser
> password = postfixpassword
> hosts = localhost, 127.0.0.1
> dbname = postfixdatabase
> query = SELECT result FROM canonical WHERE address='%s' AND active='Y'
> 
> (obvious information changed). This is unchanged before and after the
> upgrade.
> 
> The query works on all the addresses (I tested it at the mysql command
> prompt).
> 
> I also tested a local telnet to 127.0.0.1 on port 3306 which worked as
> expected and mysql responds perfectly. I also tested connection through
> the localhost socket with works as expected. Also several other parts of
> my mail system (e.g. courier_auth) connect through the socket and report
> success. And as noted, postfix is able to connect most of the time
> (aliases, virtual maildirs, etc.). Other software on my system, e.g.
> PHP, is also able to connect to mysql successfully.
> 
> I tried all the steps in the MySQL documentation on dev.mysql.com
> suggested to diagnose this error, and all confirmed that the MySQL
> server is working correctly.
> 
> So I find myself not knowing where to look next, and I hope someone here
> knows what might be happening or at least be able to point me in the
> right direction.
> 
> One additional piece of information: I am running on Mac OS/X and as
> part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus
> needing to restart my computer). This upgrade is known to break postfix.
> So I reinstalled postfix and my main.cf and master.cf files after the
> upgrade and stopped and restarted postfix to be sure. (and mysql)
> 
> What other information might be helpful in diagnosing this?
> 


- check whether any services are chrooted in master.cf (the 5th field
must be set to 'n' and not to 'y' or '-')?

- try using proxymap (foo_maps=proxy:mysql:/etc/).

- make sure the mysql socket is accessible by postfix (and not just by
root).

- try with "hosts = 127.0.0.1" (without "localhost")

why do use sender_canonical instead of canonical? rewrite should be
consistent, and "your sender is the recipient's recipient"...

issue connecting to mysql after upgrade

[Jeff Weinberger]

Hello again:

One more issue on which I would appreciate any help anyone can offer:

Yesterday I upgraded my postfix installation from 2.5.2 to 2.5.5 and  
my MySQL installation from 5.0.51b to 5.0.75. Immediately after  
restarting everything (the whole computer), I started seeing these  
messages in my mail log:


 Jan  1 09:48:35 s postfix/smtpd[13199]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
 Jan  1 09:48:35 s postfix/cleanup[13201]: warning: connect to  
mysql server localhost: Can't connect to local MySQL server through  
socket '/tmp' (38)
 Jan  1 09:48:42 s postfix/trivial-rewrite[13205]: warning:  
connect to mysql server localhost: Can't connect to local MySQL server  
through socket '/tmp' (38)


As far as I can tell this has been consistent with smtpd, cleanup and  
trivial-rewrite, but nothing else. (there have been pre-existing  
issues, per my prior conversation with mouss, with dspam, but these  
have not changed at all - they existed before the upgrade and still  
exist)


I use mysql for nearly all my tables in postfix. All of my aliases are  
working and forwarding fine, which means that postfix can access my  
mysql database (and yes, postconf -m shows mysql). virtual is finding  
the maildirs correctly for my virtual mailboxes.


However, my sender_canonical_maps are no longer working after the  
upgrade (outbound addresses are not being rewritten at all as they  
were before the upgrade)


As an example, my main.cf contains:
   sender_canonical_maps=mysql:/etc/postfix/mysql_canonical_maps.cf

and mysql_canonical_maps.cf contains:

user = postfixuser
password = postfixpassword
hosts = localhost, 127.0.0.1
dbname = postfixdatabase
query = SELECT result FROM canonical WHERE address='%s' AND  
active='Y'


(obvious information changed). This is unchanged before and after the  
upgrade.


The query works on all the addresses (I tested it at the mysql command  
prompt).


I also tested a local telnet to 127.0.0.1 on port 3306 which worked as  
expected and mysql responds perfectly. I also tested connection  
through the localhost socket with works as expected. Also several  
other parts of my mail system (e.g. courier_auth) connect through the  
socket and report success. And as noted, postfix is able to connect  
most of the time (aliases, virtual maildirs, etc.). Other software on  
my system, e.g. PHP, is also able to connect to mysql successfully.


I tried all the steps in the MySQL documentation on dev.mysql.com  
suggested to diagnose this error, and all confirmed that the MySQL  
server is working correctly.


So I find myself not knowing where to look next, and I hope someone  
here knows what might be happening or at least be able to point me in  
the right direction.


One additional piece of information: I am running on Mac OS/X and as  
part of this upgrade, I installed the 10.5.5 to 10.5.6 upgrade (thus  
needing to restart my computer). This upgrade is known to break  
postfix. So I reinstalled postfix and my main.cf and master.cf files  
after the upgrade and stopped and restarted postfix to be sure. (and  
mysql)


What other information might be helpful in diagnosing this?

Thank you for any help you can offer!

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> 
> I've been reading the dspam docs this morning and the project owner
> states fairly strongly that sendmail is far preferable to SMTP
> re-injection (in the postfix setup docs), but doesn't say why.

if he doesn't say why, then we don't know whether there was a problem at
the time or if there is another reason. People have been using smtp mode
without problems.

> I don't
> know enough about the workings of dspam (yet) to know, but I'd tend to
> agree with you on the use of SMTP as more desirable.
> 
> dspam has always had this mysql issue, which is related to its database
> of spam tokens, and I'll look into whether it might be related.
> 

I don't think it is related, but check it though...

Re: Finding the envelope-sender after always_bcc?

[Jeff Weinberger]

On Jan 1, 2009, at 9:49 AM, mouss wrote:


Jeff Weinberger a écrit :


Thank you! That helps clarify what I was missing in this - so clearly
dspam is not passing the envelope sender back to postfix.

I suspect it doesn't know how via SMTP, but it can also use the
sendmail  command to do this. I will experiment with this.



no, keep using smtp. just check your setup (and see why dspam barks
about sql errors). ask on the dspam list.

If you wnat to keep using dspam, you should follow the (recent) fork:
http://www.dspam-community.org


would the correct command be "/usr/sbin/sendmail -f" ?



yes, but smtp is better.


Thank you!

I will ask on the dspam list about this.

I've been reading the dspam docs this morning and the project owner  
states fairly strongly that sendmail is far preferable to SMTP re- 
injection (in the postfix setup docs), but doesn't say why. I don't  
know enough about the workings of dspam (yet) to know, but I'd tend to  
agree with you on the use of SMTP as more desirable.


dspam has always had this mysql issue, which is related to its  
database of spam tokens, and I'll look into whether it might be related.


Thank you for your help!

Re: RCPT TO problem using relay host

[Wietse Venema]

Dennis Putnam:
> I have a machine running postfix that is required to relay mail  
> through my ISP's mail server. When I try to send mail, I get this error:
> 
> 550 [PERMFAIL] destination not valid within DNS (in reply to RCPT TO  
> command)
> 
> Can someone explain what this error means? If I use 'telnet' to send  
> the RCTP TO command manually it accepts it.

Type the recipient domain into a DNS checking website (see search
engine for examples) and see if they report any errors.

Wietse

Re: RCPT TO problem using relay host

[mouss]

Dennis Putnam a écrit :
> I have a machine running postfix that is required to relay mail through
> my ISP's mail server. When I try to send mail, I get this error:
> 
> 550 [PERMFAIL] destination not valid within DNS (in reply to RCPT TO
> command)
> 
> Can someone explain what this error means? If I use 'telnet' to send the
> RCTP TO command manually it accepts it.
> 

please show full log lines.

RCPT TO problem using relay host

[Dennis Putnam]

I have a machine running postfix that is required to relay mail  
through my ISP's mail server. When I try to send mail, I get this error:


550 [PERMFAIL] destination not valid within DNS (in reply to RCPT TO  
command)


Can someone explain what this error means? If I use 'telnet' to send  
the RCTP TO command manually it accepts it.


Thanks.

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> 
> Thank you! That helps clarify what I was missing in this - so clearly
> dspam is not passing the envelope sender back to postfix.
> 
> I suspect it doesn't know how via SMTP, but it can also use the
> sendmail  command to do this. I will experiment with this.
> 

no, keep using smtp. just check your setup (and see why dspam barks
about sql errors). ask on the dspam list.

If you wnat to keep using dspam, you should follow the (recent) fork:
http://www.dspam-community.org

> would the correct command be "/usr/sbin/sendmail -f" ?
> 

yes, but smtp is better.

Re: Finding the envelope-sender after always_bcc?

[mouss]

jeff_homeip a écrit :
> --- In post...@yahoogroups.com, mouss  wrote:
>> Jeff Weinberger a écrit :
>>> I've verified that the "R" flag is there and I use -f ${sender} on the
>>> command line (the script does parse the arguments)
>>>
>>> I think the envelope-sender is missing before it enters the content
>>> filter. This from my mail.log:
>>>
>>> Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=,
>>> size=1505, nrcpt=1 (queue active)

look at the queue-id: A4C5E2943D74

>>> Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
>>> smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]

postfix disconnects from 69.147.64.93.

>>> Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY -
>>> NOT AN ERROR): see sql.errors for more details

dspam barks. so dspam got the message.

>>> Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1]

dspam connects to postfix (after the filter smtpd).

>>> Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
>>> client=localhost[127.0.0.1]

this dspam connection has a queue-id of 646A62943D79

>>> Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
>>> message-id=
>>> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936,
>>> nrcpt=1 (queue active)

the envelope sender is empty for queue-id 646A62943D79, which
corresponds to dspam re-injection. so dspam has reinjected the message
with an empty sender.

>>> Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1]
>>> Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
>>> to=, relay=dspam, delay=5.1,
>>> delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service)

once dspam has delivered the message, postfix tells you that the
original transaction was delivered. this comes late because dspam does
not queue mail, so postfix can't know that delivery _will_ succeed.

>>> [snip]
> 


> From this log entry it looks like the envelope sender is empty before the 
> mail is send to 
> dspam - the "from=<>" three lines before the mail is delivered to dspam makes 
> me think 
> this.
> 

don't rely on the order of log lines. Instead, look at the queue-id:

A4C5E2943D74 is the queue-id when postfix received the message from the
network. 646A62943D79 is the queue-id when postfix received the message
from localhost, which should be dspam re-injection.


> When I look at the log entries for the message when it comes back into 
> postfix from 
> dspam the envelope sender is also empty (again "from=<>"
> 

see above. the log doesn't tell you "I am about to pass mail to dspam".
it tells you "mail was delivered, and it was done via dspam". This means
that dspam took the message and said "OK" to postfix, and since dspam
doesn't have a queue manager, this means that the message was already
filtered and passed to postfix/smtpd (the "after the filter" one).

> So isn't there something losing the envelope sender before it ever gets to 
> dspam?
> 
> but to answer your question directly, dspam re-injects the mail into postfix 
> using SMTP on  
> an alternate port, the same way as is illustrated in the 
> CONTENT_FILTER_README for an 
> after-queue content filter.
> 

so the problem is in dspam.

> Does that help?
> 

I asked just to make sure it was not passing the message to something
else that does the re-injection.

Re: Finding the envelope-sender after always_bcc?

[Jeff Weinberger]

On Jan 1, 2009, at 9:31 AM, mouss wrote:


jeff_homeip a écrit :

--- In post...@yahoogroups.com, mouss  wrote:

Jeff Weinberger a écrit :
I've verified that the "R" flag is there and I use -f ${sender}  
on the

command line (the script does parse the arguments)

I think the envelope-sender is missing before it enters the content
filter. This from my mail.log:

Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=,
size=1505, nrcpt=1 (queue active)


look at the queue-id: A4C5E2943D74


Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]


postfix disconnects from 69.147.64.93.

Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO  
ONLY -

NOT AN ERROR): see sql.errors for more details


dspam barks. so dspam got the message.

Dec 31 19:50:09 s postfix/smtpd[3348]: connect from  
localhost[127.0.0.1]


dspam connects to postfix (after the filter smtpd).


Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
client=localhost[127.0.0.1]


this dspam connection has a queue-id of 646A62943D79


Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
message-id=
Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>,  
size=2936,

nrcpt=1 (queue active)


the envelope sender is empty for queue-id 646A62943D79, which
corresponds to dspam re-injection. so dspam has reinjected the message
with an empty sender.

Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from  
localhost[127.0.0.1]

Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
to=, relay=dspam, delay=5.1,
delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam  
service)


once dspam has delivered the message, postfix tells you that the
original transaction was delivered. this comes late because dspam does
not queue mail, so postfix can't know that delivery _will_ succeed.


[snip]





From this log entry it looks like the envelope sender is empty  
before the mail is send to
dspam - the "from=<>" three lines before the mail is delivered to  
dspam makes me think

this.



don't rely on the order of log lines. Instead, look at the queue-id:

A4C5E2943D74 is the queue-id when postfix received the message from  
the
network. 646A62943D79 is the queue-id when postfix received the  
message

from localhost, which should be dspam re-injection.


When I look at the log entries for the message when it comes back  
into postfix from

dspam the envelope sender is also empty (again "from=<>"



see above. the log doesn't tell you "I am about to pass mail to  
dspam".
it tells you "mail was delivered, and it was done via dspam". This  
means

that dspam took the message and said "OK" to postfix, and since dspam
doesn't have a queue manager, this means that the message was already
filtered and passed to postfix/smtpd (the "after the filter" one).

So isn't there something losing the envelope sender before it ever  
gets to dspam?


but to answer your question directly, dspam re-injects the mail  
into postfix using SMTP on
an alternate port, the same way as is illustrated in the  
CONTENT_FILTER_README for an

after-queue content filter.



so the problem is in dspam.


Does that help?



I asked just to make sure it was not passing the message to something
else that does the re-injection.




Thank you! That helps clarify what I was missing in this - so clearly  
dspam is not passing the envelope sender back to postfix.


I suspect it doesn't know how via SMTP, but it can also use the  
sendmail  command to do this. I will experiment with this.


would the correct command be "/usr/sbin/sendmail -f" ?

thanks!

Re: Rejecting emails with invalid/unlikely dates?

[Noel Jones]

mouss wrote:

Darren Pilgrim a écrit :

IBBoard wrote:

I've been looking around but so far haven't been able to find anything
(partly because it's difficult to phrase a search query!). If someone
has a solution/config for this then that'd be great.

Before anyone points out issues with GMail and lack of control, this
is all being done on a domain on a VPS. I'm just using my Gmail
address for the mailing list :)

Basically, 99% of the spam I get (which is only a small amount
compared to some people) is either a) purporting to be from me, to me
or b) has a date that Thunderbird reports as 1976 or 2038 (but is
really 3609 or just "38"). I've resolved the first part with SPF
records and checking them in Postfix, but I can't work out how to get
Postfix to reject mail that is outside a 14 day window from today (or
silently dispose of it if it's not possible because it has to get too
far in to the system to fail it).
You need a content filter for this. 


and to reject, he needs to run it in pre-queue mode (proxy_filter). or
he could use a milter such as milter-regex.


Header checks can do this; however,
they're static, so you have the problem of updating them constantly to
keep the validity window moving. 


He can use a cron to update the header_checks daily. This is "simpler"
than milter/proxy_filter.


Plus there's the issue of date
formats. 


This is not a problem here, since he wants to block "known" spam. so he
can write expressions for that spam. and if he only wants to block on
the year, then it's even easier.


The best way, IMO, is a policy service that can grok a wide
variety of date formats and check if the date is within 14 days of the
current time.



a policy service doesn't see headers. a milter or a proxy_filter does.


There are spamassassin rules for future dates in message headers, so you
might try that route instead of rolling your own.


this is indeed easier and maybe safer (well, if OP uses spamassassin).


Once upon a time, these pcre header_checks were posted to this 
list:

(beware line wrapping; each of these are a single line)

### Date checks
IF /^Date:/
/Date:.*([3-9].:..:|2[4-9]:..:|:[6-9].:|:..:6[0-9])/
HOLD invalid time in Date header

/ \d\d:\d\d:\d\d [^+-][2-9][5-9][0-9][0-9]\s*$/  HOLD invalid 
time zone offset in Date header



/^Date: .* 19[0-9][0-9]/   HOLD UBE Header - Past Date #1
/^Date: .* 200[0-6]/   HOLD UBE Header - Past Date #2

/^Date:.*((3[2-9]|[4-9][0-9]) Jan|[3-9][0-9] 
Feb|(3[2-9]|[4-9][0-9]) Mar|(3[1-9]|[4-9][0-9]) 
Apr|(3[2-9]|[4-9][0-9]) May|(3[
1-9]|[4-9][0-9]) Jun|(3[2-9]|[4-9][0-9]) 
Jul|(3[2-9]|[4-9][0-9]) Aug|(3[1-9]|[4-9][0-9]) 
Sep|(3[2-9]|[4-9][0-9]) Oct|(3[1-9]
|[4-9][0-9]) Nov|(3[2-9]|[4-9][0-9]) Dec)/   HOLD Invalid date 
header. Correct your clock and resend please.


/^Date:.*(2[4-9]:[0-9]{2}:[0-9]{2}|[3-9][0-9]:[0-9]{2}:[0-9]{2}|[0-9]{1,2}:[6-9][0-9]:[0-9]{2}|[0-9]{1,2}:[0-9]{2}:(6[2-9]|[
7-9][0-9]))/   HOLD Invalid time header. Correct your clock 
and resend please.


ENDIF
### END DATE CHECKS

I have these set to HOLD since they rarely catch anything 
other than the occasional legit mail with a bad year.  YMMV.


--
Noel Jones

Re: Finding the envelope-sender after always_bcc?

[Jeff Weinberger]

mouss wrote:


Jeff Weinberger a écrit :
>
> I've verified that the "R" flag is there and I use -f ${sender} on  
the

> command line (the script does parse the arguments)
>
> I think the envelope-sender is missing before it enters the content
> filter. This from my mail.log:
>
> Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=>,

> size=1505, nrcpt=1 (queue active)
> Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
> smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
> Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO  
ONLY -

> NOT AN ERROR): see sql.errors for more details
> Dec 31 19:50:09 s postfix/smtpd[3348]: connect from  
localhost[1270.0.1]

> Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
> client=localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
> message-id=
> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>,  
size=2936,

> nrcpt=1 (queue active)
> Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from  
localhost[127.0.0.1]

> Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
> to=, relay=dspam, delay=5.1,
> delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam  
service)

>
> (identifying information removed)
>
> The "from=<>" in the third-to-last line I assume should be the
> envelope-sender?
>

yes. when mail is passed back to postfix, something loses the
envelope-sender. how do you pass mail from dspam to postfix?



From this log entry it looks like the envelope sender is empty before  
the mail is send to dspam - the "from=<>" three lines before the mail  
is delivered to dspam makes me think this.


When I look at the log entries for the message when it comes back into  
postfix from dspam the envelope sender is also empty (again "from=<>"


So isn't there something losing the envelope sender before it ever  
gets to dspam?


but to answer your question directly, dspam re-injects the mail into  
postfix using SMTP on  an alternate port, the same way as is  
illustrated in the CONTENT_FILTER_README for an after-queue content  
filter.


Does that help? or point to anything?

Re: How to bounce back a mail in queue

[Tomasz Suchodolski]

ram pisze:
> Sometimes my mailq gets cluttered with lot of undelivearble mails.
> Because end servers are not accepting
> 
> I wish to bounce back some messages ( not delete them ) from queue 
> 
> How do I do it ? 
> 

Also search archive for: "manually bounce mail in queue"
http://www.irbs.net/internet/postfix/0705/1073.html

Tomasz Suchodolski

Re: How to bounce back a mail in queue

[Terry Carmen]

ram wrote:

Sometimes my mailq gets cluttered with lot of undelivearble mails.
Because end servers are not accepting

I wish to bounce back some messages ( not delete them ) from queue 

How do I do it ? 



  

The mail will bounce on it's own when it's maximal_queue_lifetime expires.

Terry

Re: Looping in new production machine!

[mouss]

Rich Winkel a écrit :
> I'm not sure, I may have an unusual dns setup on this mail server.
> The primary host name is math.missouri.edu, but it has an alias of
> math.math.missouri.edu.  In any case, I'm getting the dreaded:
> 
> status=SOFTBOUNCE (mail for math.math.missouri.edu loops back to myself)
> 
> Even though incoming messages are addressed to x...@math.missouri.edu.
> Yet it doesn't happen to all incoming messages.  Has anyone seen this
> behavior?
> 
> Here are the relevant variables from main.cf:
> mydomain = math.missouri.edu
> myhostname = math.missouri.edu
> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
> inet_interfaces = $myhostname, localhost
> 

either add math.math.missouri.edu to mydestination or set
myhostname = math.math.missouri.edu

Re: Finding the envelope-sender after always_bcc?

[mouss]

Jeff Weinberger a écrit :
> 
> I've verified that the "R" flag is there and I use -f ${sender} on the
> command line (the script does parse the arguments)
> 
> I think the envelope-sender is missing before it enters the content
> filter. This from my mail.log:
> 
> Dec 31 19:50:07 s postfix/qmgr[3345]: A4C5E2943D74: from=,
> size=1505, nrcpt=1 (queue active)
> Dec 31 19:50:07 s postfix/smtpd[3340]: disconnect from
> smtp120.isp.mail.sp1.myisp.tld[69.147.64.93]
> Dec 31 19:50:07 s dspam[3356]: query error: VERBOSE DEBUG (INFO ONLY -
> NOT AN ERROR): see sql.errors for more details
> Dec 31 19:50:09 s postfix/smtpd[3348]: connect from localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/smtpd[3348]: 646A62943D79:
> client=localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/cleanup[3344]: 646A62943D79:
> message-id=
> Dec 31 19:50:09 s postfix/qmgr[3345]: 646A62943D79: from=<>, size=2936,
> nrcpt=1 (queue active)
> Dec 31 19:50:09 s postfix/smtpd[3348]: disconnect from localhost[127.0.0.1]
> Dec 31 19:50:09 s postfix/pipe[3346]: A4C5E2943D74:
> to=, relay=dspam, delay=5.1,
> delays=3.4/0/0/1.7, dsn=2.0.0, status=sent (delivered via dspam service)
> 
> (identifying information removed)
> 
> The "from=<>" in the third-to-last line I assume should be the
> envelope-sender?
> 

yes. when mail is passed back to postfix, something loses the
envelope-sender. how do you pass mail from dspam to postfix?

> This happens whether I send from my ISP mail address, another
> locally-hosted virtual mailbox or anywhere else.
> 
> Is this part of the problem?
> 
> If so, where can I start to look for a solution? or what information
> would be helpful?
> 
> Thank you!
> 
> 

Re: Looping in new production machine!

[Dario "subbia" Cavallaro]

Rich Winkel ha scritto:

I'm not sure, I may have an unusual dns setup on this mail server.
The primary host name is math.missouri.edu, but it has an alias of
math.math.missouri.edu.  In any case, I'm getting the dreaded:

status=SOFTBOUNCE (mail for math.math.missouri.edu loops back to myself)

Even though incoming messages are addressed to x...@math.missouri.edu.
Yet it doesn't happen to all incoming messages.  Has anyone seen this
behavior?

Here are the relevant variables from main.cf:
mydomain = math.missouri.edu
myhostname = math.missouri.edu
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
inet_interfaces = $myhostname, localhost

HELP!!!

Rich

  

Why mydomain and myhostname are the same set?

Is relay_domains set the same as mydestination? If the answer is yes, 
could be this the issue.


Please report all configuration files, as explained in: 
http://www.postfix.org/DEBUG_README.html#mail for better troubleshooting.


Hth.

Cheers

Dario "subbia" Cavallaro

How to bounce back a mail in queue

[ram]

Sometimes my mailq gets cluttered with lot of undelivearble mails.
Because end servers are not accepting

I wish to bounce back some messages ( not delete them ) from queue 

How do I do it ?