Re: BackScatter Problem

[jan gestre]

> If it's backscatter, it should be coming from <>, not a "valid company
> address".  Please show your logs during delivery of the alleged backscatter.
>

I don't have anymore the logs from Postfix and I'm not sure if it
really is a backscatter problem, all I have right now is the
following:

--
-Original Message-
From: Judy Aguilar [mailto:judyagui...@example.com]
Sent: Tuesday, May 26, 2009 4:41 PM
To: Sheila Villanueva
Subject: Fw: No branding needed!

Pls see "VIAGRA.Official Site's email address -- creati...@example.com

Fyi.

- Original Message - From: "Biba Cabuquit" 
To: "VIAGRA . Official Site" 
Sent: Tuesday, May 26, 2009 3:16 PM
Subject: No branding needed!

--- end-

The creati...@example.com is a valid email address and yet it has the
name VIAGRA Official site, is the mail server the causing the issue or
there is a worm on the users PC that' causing this.


>> My /etc/postfix/header_checks contain only the following:
>>
>> /^Received:/ HOLD
>
> Very odd that you want to hold ALL email with this check.  Does MailScanner
> examine messages in the hold queue and then release them?
>

MailScanner really examines messages in the HOLD queue because all
emails incoming/outgoing are tagged by MailScanner as having scanned
or I'm totally wrong?

RE: BackScatter Problem

[MacShane, Tracy]

 

> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of jan gestre
> Sent: Wednesday, 27 May 2009 5:00 PM
> To: postfix-users@postfix.org
> Subject: Re: BackScatter Problem
> 
> > If it's backscatter, it should be coming from <>, not a 
> "valid company 
> > address".  Please show your logs during delivery of the 
> alleged backscatter.
> >
> 
> I don't have anymore the logs from Postfix and I'm not sure 
> if it really is a backscatter problem, all I have right now is the
> following:
> 
> --
> -Original Message-
> From: Judy Aguilar [mailto:judyagui...@example.com]
> Sent: Tuesday, May 26, 2009 4:41 PM
> To: Sheila Villanueva
> Subject: Fw: No branding needed!
> 
> Pls see "VIAGRA.Official Site's email address -- creati...@example.com
> 
> Fyi.
> 
> - Original Message - From: "Biba Cabuquit" 
> 
> To: "VIAGRA . Official Site" 
> Sent: Tuesday, May 26, 2009 3:16 PM
> Subject: No branding needed!
> 
> --- end-
> 
> The creati...@example.com is a valid email address and yet it 
> has the name VIAGRA Official site, is the mail server the 
> causing the issue or there is a worm on the users PC that' 
> causing this.
> 
> 
> >> My /etc/postfix/header_checks contain only the following:
> >>
> >> /^Received:/ HOLD
> >
> > Very odd that you want to hold ALL email with this check.  Does 
> > MailScanner examine messages in the hold queue and then 
> release them?
> >
> 
> MailScanner really examines messages in the HOLD queue 
> because all emails incoming/outgoing are tagged by 
> MailScanner as having scanned or I'm totally wrong?
> 


While others might have better luck trying to divine why you're getting the 
spam, it's very difficult to do so with a couple of message snips (you haven't 
even included the full headers). However, as a guess, someone is spoofing the 
"creati...@example.com" to send spam, and now you're getting the backscatter. 
It could be any machine on the internet spoofing that address.

As for Mailscanner, perhaps it's better to ask over on their support site. If 
you look at the Addons page on the postfix.org site, it says "* mailscanner 
system, works with Postfix and other MTAs. WARNING: This software uses 
unsupported methods to manipulate Postfix queue files directly. This will 
result in corruption or loss of mail. The mailscanner authors have sofar 
refused to discuss a proper access API or protocol."

Re: message_size_limit,

[Trigve Siver]

Hi,

> From: mouss 

> what you could do is run a script that
> - checks the message size. if it's too large, store it somewhere for review
> - else, run sendmail
> 
> in any case, don't bounce without some sort of verification (some
> anti-spam checks or a manual review).
> 
> If you are willing to do more scripting, consider putting the large
> messages on a web server and letting the user get them there. this needs
> some work (create random URL, notify user, ... purge after some time,
> ...).

This solution looks nice but I don't have much experience with scripting nor do 
I have so much time to experiment with it. As I wrote in a previous mail it 
will be great if postfix have some option to accept mail and than bounce it 
back. This problem with big messages arise only 3-5 for a year and till now it 
wasn't spam.

thanks

Trigve



  

Re: user permissions

[Nicolas Michel]

Thank you a lot.
I didn't know that solution.


Le mardi 26 mai 2009 à 07:34 -0500, Noel Jones a écrit :

> Nicolas Michel wrote:
> > Thanks for your help. But that tips is not really what I'm searching 
> > for. The class restriction is a global restriction : some users have 
> > full permission (and can send mail to local and remote users) and some 
> > others have restricts permissions (they can only send to local users). 
> > So there are in fact two groups. And every user in each group have the 
> > same permission.
> > 
> > What I wanted to do is at a higher granularity level : I want that 
> > _each_ user have his own white list of authorized users to who he can 
> > send mails ; sorts of ACL for mail (and each user is an object).
> 
> This requires a policy server.  The general documentation can 
> be found here:
> http://www.postfix.org/SMTPD_POLICY_README.html
> 
> You can either write your own policy server, or use a 
> pre-existing one.
> http://www.postfix.org/addon.html#policy
> 
> 
>-- Noel Jones

Re: BackScatter Problem

[kj]

jan gestre wrote:

I don't have anymore the logs from Postfix and I'm not sure if it
really is a backscatter problem, all I have right now is the
following:


The message snippet is of no use.  Can you post the full headers?  That 
and a corresponding log entry should clear things up.


From what you've said so far it sounds more likely to be a forged 
return-path/from, in which case adding and checking against spf records 
would solve your issue.


--kj

NetBSD 5

[J.D. Bronson]

I noticed that postfix doesn't recognize NetBSD 5:

This is as far as makedefs goes..
makedefs:   NetBSD.4*)  SYSTYPE=NETBSD4

as a test, I did this:
makedefs:   NetBSD.5*)  SYSTYPE=NETBSD4

and it compiled just fine.

-JD

Re: NetBSD 5

[Wietse Venema]

J.D. Bronson:
> I noticed that postfix doesn't recognize NetBSD 5:
> 
> This is as far as makedefs goes..
> makedefs:   NetBSD.4*)  SYSTYPE=NETBSD4
> 
> as a test, I did this:
> makedefs:   NetBSD.5*)  SYSTYPE=NETBSD4
> 
> and it compiled just fine.

Postfix will recognize NetBSD 5 after it has been verified to fully
support the existing Postfix features.

One known bug is that file descriptor passing requires different
code on NetBSD than on the other 64-bit systems. This breaks Milters,
the SMTP connection cache, and other features that pass sockets
over UNIX-domain sockets.

Wietse

smtp_sasl_mechanism_filter doesn't wok

[Zero Zeibov]

I try to limit auth mech in postfix 2.6.1 on FreeBSD 6.4. For this
I've added to main.conf:

smtp_sasl_mechanism_filter = plain, login

But simple test by telnet shows following:

Connected to x.x.x.x.
Escape character is '^]'.
220 xxx.xxx.com.ua ESMTP Postfix
ehlo 1
250-xxx.xxx.com.ua
250-PIPELINING
250-SIZE 1024
250-ETRN
250-STARTTLS
250-AUTH NTLM LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5
250-AUTH=NTLM LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

I also tried to limit auth mechs in /usr/local/lib/sasl2/smtpd.conf
pwcheck_method: saslauthd
mechlist: PLAIN LOGIN
But it doesn't help.
How I can remove such auth mechs as GSSAPI DIGEST-MD5 CRAM-MD5?

Re: smtp_sasl_mechanism_filter doesn't wok

[Ralf Hildebrandt]

* Zero Zeibov :
> I try to limit auth mech in postfix 2.6.1 on FreeBSD 6.4. For this
> I've added to main.conf:
> 
> smtp_sasl_mechanism_filter = plain, login

smtpd_sasl_mechanism_filter = plain, login

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
"General Failure's Fault. Not Yours."  -Anon.  

Re: smtp_sasl_mechanism_filter doesn't wok

[Zero Zeibov]

Here's filtered output from postconf

# postconf | grep sasl_mechanism
lmtp_sasl_mechanism_filter =
smtp_sasl_mechanism_filter = plain, login

I didn't find option smtpd_sasl_mechanism_filter on postfix manual

2009/5/27 Ralf Hildebrandt :
> * Zero Zeibov :
>> I try to limit auth mech in postfix 2.6.1 on FreeBSD 6.4. For this
>> I've added to main.conf:
>>
>> smtp_sasl_mechanism_filter = plain, login
>
> smtpd_sasl_mechanism_filter = plain, login
>
> --
> Ralf Hildebrandt
> Postfix - Einrichtung, Betrieb und Wartung       Tel. +49 (0)30-450 570-155
> http://www.computerbeschimpfung.de
> "General Failure's Fault. Not Yours."  -Anon.
>

Re: NetBSD 5

[J.D. Bronson]

Wietse Venema wrote:


Postfix will recognize NetBSD 5 after it has been verified to fully
support the existing Postfix features.

One known bug is that file descriptor passing requires different
code on NetBSD than on the other 64-bit systems. This breaks Milters,
the SMTP connection cache, and other features that pass sockets
over UNIX-domain sockets.

Wietse

.



Thanks. I am not running in 64bit mode and have not noticed anything odd 
in the way I run postfix...at least not yet :-)


-JD

Re: BackScatter Problem

[Sahil Tandon]

On Wed, 27 May 2009, kj wrote:

> jan gestre wrote:
>> I don't have anymore the logs from Postfix and I'm not sure if it
>> really is a backscatter problem, all I have right now is the
>> following:
>
> The message snippet is of no use.  Can you post the full headers?  That  
> and a corresponding log entry should clear things up.

FWIW, the snippet alone hits Sanesecurity.Hdr.9913.UNOFFICIAL.

-- 
Sahil Tandon 

Re: log query

[Sahil Tandon]

On Tue, 26 May 2009, LuKreme wrote:

> On 26-May-2009, at 17:39, Lists wrote:
>> As part of my mail system I am using postgrey.
>>
>> When stuff is stopped at the gate (so to speek) i.e. it doesn't even  
>> get into the the system is there a log kept of this?
>
> postgrey logs to the maillog. lines look like this:

I believe postgrey too logs to syslog's mail facility, so the file depends on
the system/configuration, and is probably not maillog on all platforms.

-- 
Sahil Tandon 

Re: smtp_sasl_mechanism_filter doesn't wok

[Wietse Venema]

Zero Zeibov:
> I try to limit auth mech in postfix 2.6.1 on FreeBSD 6.4. For this
> I've added to main.conf:
> 
> smtp_sasl_mechanism_filter = plain, login

Read carefully.

AS DOCUMENTED, this applies to the Postfix SMTP CLIENT.

Wietse

> But simple test by telnet shows following:
> 
> Connected to x.x.x.x.
> Escape character is '^]'.
> 220 xxx.xxx.com.ua ESMTP Postfix
> ehlo 1
> 250-xxx.xxx.com.ua
> 250-PIPELINING
> 250-SIZE 1024
> 250-ETRN
> 250-STARTTLS
> 250-AUTH NTLM LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5
> 250-AUTH=NTLM LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> 
> I also tried to limit auth mechs in /usr/local/lib/sasl2/smtpd.conf
> pwcheck_method: saslauthd
> mechlist: PLAIN LOGIN

Why do you believe that this is the correct pathname for the file?

Wietse

> But it doesn't help.
> How I can remove such auth mechs as GSSAPI DIGEST-MD5 CRAM-MD5?
> 
> 

Re: smtp_sasl_mechanism_filter doesn't wok

[Victor Duchovni]

On Wed, May 27, 2009 at 02:11:26PM +0300, Zero Zeibov wrote:

> I didn't find option smtpd_sasl_mechanism_filter on postfix manual

It does not exist. Server-side SASL mechanism lists are set in
the server's SASL configuration file.

-- 
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: message_size_limit,

[Victor Duchovni]

On Wed, May 27, 2009 at 12:35:28AM -0700, Trigve Siver wrote:

> 
> Hi,
> 
> > From: mouss 
> 
> > what you could do is run a script that
> > - checks the message size. if it's too large, store it somewhere for review
> > - else, run sendmail
> > 
> > in any case, don't bounce without some sort of verification (some
> > anti-spam checks or a manual review).
> > 
> > If you are willing to do more scripting, consider putting the large
> > messages on a web server and letting the user get them there. this needs
> > some work (create random URL, notify user, ... purge after some time,
> > ...).
> 
> This solution looks nice but I don't have much experience with scripting nor 
> do I have so much time to experiment with it. As I wrote in a previous mail 
> it will be great if postfix have some option to accept mail and than bounce 
> it back. This problem with big messages arise only 3-5 for a year and till 
> now it wasn't spam.

Just set your message_size_limit larger than the ISP's limit and you are
done. If you want Postfix to bounce large mail, configure an SMTP nexthop
(perhaps a content_filter) whose limit is smaller.

-- 
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: How to safely re-inject an archived queue file?

[Curtis]

Wietse: 
> Curtis:
> > > This is safe only when the maildrop queue is "stopped", that is,
> > >
> > > 1) No submissions with the Postfix sendmail command while these
> > >files are in the maildrop directory, otherwise mail will be
> > >lost.


I'm still trying to understand why mail would be lost.  Since it would be
impossible for the Postfix sendmail command to overwrite one of these files
due to a filename conflict (we write the files using filenames that would
never be used by Postfix), are you saying that the risk of mail loss comes
because Postfix might use the same inode as one of these existing files?
Doesn't postfix use some type of system call to retrieve an inode number
that is not already in use?  

> > >
> > > 2) No pickup daemon and no postsuper command, otherwise pickup will
> > >read incomplete files and throw them away, or it will make
> > >duplicate deliveries as files get renamed.


So the assertion that has been made here in the past (not by you) about
creating the file using mode 0600 to prevent pickup from seeing incomplete
files is false?

Thanks,

Curtis

Re: How to safely re-inject an archived queue file?

[Victor Duchovni]

On Wed, May 27, 2009 at 11:05:50AM -0600, Curtis wrote:

> I'm still trying to understand why mail would be lost.  Since it would be
> impossible for the Postfix sendmail command to overwrite one of these files
> due to a filename conflict (we write the files using filenames that would
> never be used by Postfix), are you saying that the risk of mail loss comes
> because Postfix might use the same inode as one of these existing files?
> Doesn't postfix use some type of system call to retrieve an inode number
> that is not already in use?  

There's a difference between what will happen under the current
implementation of Postfix, and what is guaranteed to happen by
documentation, ...

> > > > 2) No pickup daemon and no postsuper command, otherwise pickup will
> > > >read incomplete files and throw them away, or it will make
> > > >duplicate deliveries as files get renamed.
> 
> 
> So the assertion that has been made here in the past (not by you) about
> creating the file using mode 0600 to prevent pickup from seeing incomplete
> files is false?

The approach you have taken, will not collide with the current Postfix
*implementation*, provided you don't run "postsuper" and your code at
the same time. If "postsuper" (which runs durin "reload") is to be
allowed to race against your code, your mode 0700 file names have to
match the usual Postfix hex file names:



this is an undocumented interface, so you have to be willing to review
any Postfix release for compatibility prior to deployment.

-- 
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.

virtual_alias_domains and virtual_maps

[gabriele]

Hi list !
I run a python script which is a mail2news gateway for usenet postings.
This script allows people without a proper usenet client to post to
newsgroups by email client .
The procedure is to write the interested newsgroups where to post to in
the user part of the email address plus a date field like this:
mail2news-mmdd-alt.test.newsgr...@m2n.mydomain .
I have a main domain name mydomain.com and i have made a subdomain
m2n.mydomain.com and i have included both in a virtual_alias_domains . I
have configured also the vitual_maps with a catch-all domain entry like
@m2n.mydomain   mail2news (user who owns the m2n python script) which is
what i need for the above said user part for the mail2news gateway to
work. I'm getting lots of mail bounced and 'user missing in virtual'
maps and i needed some advices on ho to best implement the virtual
aliases .
Thanks

Gab
-- 
sec   1024D/BCF27E42 2009-04-12 [expires: 2010-04-12]
Key fingerprint = 437A 8A2E 2CE0 7044 CB6A  996B A426 2C72 BCF2 7E42




signature.asc
Description: OpenPGP digital signature

Re: How to safely re-inject an archived queue file?

[Wietse Venema]

Curtis:
> Wietse: 
> > Curtis:
> > > > This is safe only when the maildrop queue is "stopped", that is,
> > > >
> > > > 1) No submissions with the Postfix sendmail command while these
> > > >files are in the maildrop directory, otherwise mail will be
> > > >lost.
> 
> 
> I'm still trying to understand why mail would be lost.  Since it would be
> impossible for the Postfix sendmail command to overwrite one of these files
> due to a filename conflict (we write the files using filenames that would
> never be used by Postfix), are you saying that the risk of mail loss comes
> because Postfix might use the same inode as one of these existing files?
> Doesn't postfix use some type of system call to retrieve an inode number
> that is not already in use?  

File names and file permissions are Postfix-private implementation
details that are subject to change without prior notice. The name
of the file is used as the queue ID in logging, but the way that
the name or permissions are chosen is private.

I promise only that Postfix will read queue files that are created
by its own programs, even after files are moved to the maildrop
queue with "postsuper -r".

To inject Postfix queue files from elsewhere, the only safe way is
to do this in a quiescent queue: a queue that has no READ activity
and no WRITE activity.

In addition, think it is a mistake to inject mail from elsewhere
into the maildrop queue.  My best bet is that you import files into
a quiescent hold queue (i.e. no other software is doing HOLD actions
in access maps etc.) and that you run "postsuper hold" until the
file names stop changing, then use "postsuper -r" to move the files
to the maildrop queue.  This way you don't have to work around
collisions with sendmail/postdrop submissions, or about collisions
with pickup daemons that read files before they are complete.

I must be able to change the private internals or else it will be
impossible to improve Postfix. Software that depends on such
internals is not and will not be covered by my guarantee.

Wietse

Re: How to safely re-inject an archived queue file?

[Wietse Venema]

Victor Duchovni:
> the same time. If "postsuper" (which runs durin "reload") is to be
> allowed to race against your code, your mode 0700 file names have to
> match the usual Postfix hex file names:
> 
>   
> 
> this is an undocumented interface, so you have to be willing to review
> any Postfix release for compatibility prior to deployment.

Sorry, the RELEASE_NOTES don't discuss undocumented behavior.

If they don't want to stop Postfix, the safe method is to import
Postfix queue files from elsewhere into the HOLD queue, assuming
that there is no other file activity in that queue, followed by
repeated use of "postsuper hold" and finally "postsuper -r".

Wietse

Re: How to safely re-inject an archived queue file?

[Terry Carmen]

I've already been down this road. Forget about playing with queue file names,
permissions and all the other "back door" methods of accessing the queues, and
use the utilities supplied.

Calling an external app to make things happen isn't quite as elegant as being
able to drop files where you want them, however you also won't get angry phone
calls about missing or "stuck" mail.

If you consider the potential visibility, nobody except you will know that
you're holding, releasing and re-injecting mail using external applications,
however if you guess wrong mess up or something changes in postfix and breaks
your stuff, *everybody* will know.

Terry

Re: How to safely re-inject an archived queue file?

[Victor Duchovni]

On Wed, May 27, 2009 at 02:25:24PM -0400, Wietse Venema wrote:

> Victor Duchovni:
> > the same time. If "postsuper" (which runs durin "reload") is to be
> > allowed to race against your code, your mode 0700 file names have to
> > match the usual Postfix hex file names:
> > 
> > 
> > 
> > this is an undocumented interface, so you have to be willing to review
> > any Postfix release for compatibility prior to deployment.
> 
> Sorry, the RELEASE_NOTES don't discuss undocumented behavior.
> 

By "review", I meant "read the code"... Postfix is open-source
software, if they are willing to take on the burden of supporting local
"customization" (their injection system can be viewed as a customization),
and the reasons to do so are sufficiently compelling, they are free to
customize Postfix, but then they have to "port" their custom feature to
new releases, which requires going beyond the RELEASE_NOTES, ...

Yes, code that knows the detailed format of queue files is outside the
normal contract.

They could reduce the likelihood of breakage, by writing to the maildrop
directory of a dormant queue in the same file-system, and running
"postsuper -s" to rename the files added to the dormant queue, and then
rename(2) the resulting files into the non-dormant queue for pickup(8)
processing. The cost is additional fork/exec of postsuper for each batch
of injected messages.

-- 
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: How to safely re-inject an archived queue file?

[Wietse Venema]

Victor Duchovni:
> On Wed, May 27, 2009 at 02:25:24PM -0400, Wietse Venema wrote:
> 
> > Victor Duchovni:
> > > the same time. If "postsuper" (which runs durin "reload") is to be
> > > allowed to race against your code, your mode 0700 file names have to
> > > match the usual Postfix hex file names:
> > > 
> > >   
> > > 
> > > this is an undocumented interface, so you have to be willing to review
> > > any Postfix release for compatibility prior to deployment.
> > 
> > Sorry, the RELEASE_NOTES don't discuss undocumented behavior.
> > 
> 
> By "review", I meant "read the code"... Postfix is open-source
> software, if they are willing to take on the burden of supporting local
> "customization" (their injection system can be viewed as a customization),
> and the reasons to do so are sufficiently compelling, they are free to
> customize Postfix, but then they have to "port" their custom feature to
> new releases, which requires going beyond the RELEASE_NOTES, ...
> 
> Yes, code that knows the detailed format of queue files is outside the
> normal contract.
> 
> They could reduce the likelihood of breakage, by writing to the maildrop
> directory of a dormant queue in the same file-system, and running
> "postsuper -s" to rename the files added to the dormant queue, and then
> rename(2) the resulting files into the non-dormant queue for pickup(8)
> processing. The cost is additional fork/exec of postsuper for each batch
> of injected messages.

That breaks when files are moved across file system boundaries.

The documented safe way to "restore" queue files is to stop Postfix,
dump files into the maildrop directory, and run "postsuper" until
the names stop changing.

Without stopping Postfix, importing files safely could be done with
a new "postdrop" command-line option.  This would be a privileged
option, since real queue files contain records that users are not
allowed to provide.

Wietse

RE: How to safely re-inject an archived queue file?

[Curtis]

> >
> > Sorry, the RELEASE_NOTES don't discuss undocumented behavior.
> >
> 
> By "review", I meant "read the code"... Postfix is open-source
> software, if they are willing to take on the burden of supporting local
> "customization" (their injection system can be viewed as a
> customization),
> and the reasons to do so are sufficiently compelling, they are free to
> customize Postfix, but then they have to "port" their custom feature to
> new releases, which requires going beyond the RELEASE_NOTES, ...

Thanks for your input on this, Viktor.  I should have specified in my posts
that I was referring to how to safely do maildrop injections in the current
implimentation of Postfix only.  We realize that this will put us in the
position of always having to review whether it's still safe with newer
versions of Postfix.  


> 
> Yes, code that knows the detailed format of queue files is outside the
> normal contract.
> 
> They could reduce the likelihood of breakage, by writing to the
> maildrop
> directory of a dormant queue in the same file-system, and running
> "postsuper -s" to rename the files added to the dormant queue, and then
> rename(2) the resulting files into the non-dormant queue for pickup(8)
> processing. The cost is additional fork/exec of postsuper for each
> batch
> of injected messages.


For the moment, we are trying to avoid running postsuper -s, as it was
suggested that it may be costly to do so.

For those wondering why we can't just commit to only using the provided
utilities to manipulate queue files, it's because we are giving individual
users the ability to view messages that were placed in the hold queue and
release them up to 30 days after the messages were originally placed there.
While we could do this without moving the files out the hold queue, if we
were to leave them there, the number of files in the one directory would
cause us to take a performance hit all on it's own.  On our test system,
that only hosts a few busy domains, the number of queue files that we
collected from the hold queue on our test system, after just a few weeks, is
over 200,000.   On the production systems that will filter for hundreds of
domains per machine, I expect that we'll see that many messages being held
in the hold queue in a single day.  Multiply that times 30 days, and I think
it would be trouble.

I would be interested in seeing an option in Postfix to have the hold queue
support multiple subdirectories where new subdirectories are created every X
hours (or perhaps just daily) so that the number of files sitting in the
queue do not get unmanagable.  Until then, I think we are stuck with having
to do some manual manipulation and being very careful that we understand the
file management of the version of Postfix that we're running.

I think, based on the comments we've received so far, that we're safe doing
what we're doing on the current Postfix implimentation.  (And again, I
appreciate everyone's comments on this... I am not responding to everyone's
comments to reduce the footprint I've already made on this list for an issue
that is probably pretty unique to our situation.)

Curtis

> 
> --
>   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: How to safely re-inject an archived queue file?

[Curtis]

Wietse:
> Without stopping Postfix, importing files safely could be done with
> a new "postdrop" command-line option.  This would be a privileged
> option, since real queue files contain records that users are not
> allowed to provide.

That would be terrific... and would seemingly resolve all concerns.  I would
love to see that.
 
Curtis

> 
>   Wietse

Re: Disable content_filter (Solved!)

[Simon Schelkshorn]

> > The problem is, that I can send mail to the listener on 
> > 192.168.xxx.xxx on port 25, but that it is passed to the 
> > postfixfilter. My question is, how can I completely turn off 
> > contentfiltering for all mail received on 192.168.xxx.xxx and why 
> > does the "-o content_filter=" option turn off contentfiltering for 
> > the listener on localhost and not for the one on 192.168.xxx.xxx?

I have two servers with identical configuration. During debugging I 
found, that only one of the two servers suffers from this problem. A 
diff on the two main.cf revealed the cause.

On the server with the problem the address of the 192.168.xxx.xxx 
listener was listed in the inet_interfaces. It seems that in this 
case the definition of the "smtp" listener has a higher priority. 
After removing the address from inet_interfaces everything works now 
as expected.

BR,
Simon

Re: How to safely re-inject an archived queue file?

[Victor Duchovni]

On Wed, May 27, 2009 at 01:47:27PM -0600, Curtis wrote:

> For those wondering why we can't just commit to only using the provided
> utilities to manipulate queue files, it's because we are giving individual
> users the ability to view messages that were placed in the hold queue and
> release them up to 30 days after the messages were originally placed there.

If the files are guaranteed to only have a single recipient at the point
in your processing stream at which they are "held", you don't have to do
anything nearly so complex. Just retain the file's original name and
inode, by renaming it into a suitable directory tree in the same file-system.

Releasing can be accomplished by just moving it back into the maildrop queue
with its original name.

> While we could do this without moving the files out the hold queue, if we
> were to leave them there, the number of files in the one directory would
> cause us to take a performance hit all on it's own. 

*Moving* the files does not require you to delete them or to change the
queue file name, just move them to a dedicated directory tree in the same
file-system.

> On our test system,
> that only hosts a few busy domains, the number of queue files that we
> collected from the hold queue on our test system, after just a few weeks, is
> over 200,000.   On the production systems that will filter for hundreds of
> domains per machine, I expect that we'll see that many messages being held
> in the hold queue in a single day.  Multiply that times 30 days, and I think
> it would be trouble.

I have a 30-day quarantine also, the files are kept in the original
file-system. On each of 6 servers, I have ~275,000 held files, ~13GB of
storage. It sounds like your scale is much larger.

A better design (working on this for our next gen quarantine) is I think
to deliver the quarantined messages to a custom SMTP or LMTP agent that
saves the message envelope and data in an ASCII form. Then messages
released by users from the quarantine are re-injected also via SMTP.

> I would be interested in seeing an option in Postfix to have the hold queue
> support multiple subdirectories where new subdirectories are created every X
> hours (or perhaps just daily) so that the number of files sitting in the
> queue do not get unmanagable.

Far better to not use HOLD. FILTER instead.

-- 
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: How to safely re-inject an archived queue file?

[Wietse Venema]

Wietse Venema:
> The Postfix queue is designed to be a short-term message store
> where files can be located quickly based on their name alone.
> 
> I don't think it is a good idea to re-purpose this design for
> routine long-term storage of messages waiting for approval, or to
> break the design by making file locations dependent on properties
> other than the file name.
> 
> I also don't think that re-injection queue files directly into the
> queue is a good idea.  Moving files back into the queue after
> several days breaks more things than we discussed sofar.
> 
> For example, re-injected files will be past their expiration time.
> This breaks another fundamental assumption of the queue file life
> cycle, namely that there will be multiple delivery attempts before
> a message expires. And you'd have the same problem with other MTAs.
> 
> If your infrastructure requires a review cycle, then it makes no
> sense to keep that mail in the Postfix queue. The messages should
> be given to a (web-based?) review system, and that system should
> submit approved email via SMTP or /usr/sbin/sendmail to Postfix,
> preserving the old contents and the old envelope sender/recipient.

Combining this with part of Victor's mail, the setup would look
as follows:

Invoke the Postfix FILTER action to pass to-be-approved mail via
SMTP or LMTP to quarantine system. This way the Postfix queue is
used for the designed purpose:  short-term storage, and any problems
with the quarantine system will be handled via the usual SMTP retry
mechanisms. To avoid unnecessary chattiness, you may want to disable
DSN announcements in the perimeter server's EHLO responses.

The quarantine system uses a file organization that is more optimized
for longer-term storage, and for access patterns that are typical
for quarantine systems.

Once mail is approved, inject via SMTP or /usr/sbin/sendmail into
Postfix, so that the messages start with a fresh expiration cycle.

No screwing around with inodes, file names, and other Postfix-internal
details that will get you locked in on an obsolecent release.

Wietse

Re: How to safely re-inject an archived queue file?

[Wietse Venema]

The Postfix queue is designed to be a short-term message store
where files can be located quickly based on their name alone.

I don't think it is a good idea to re-purpose this design for
routine long-term storage of messages waiting for approval, or to
break the design by making file locations dependent on properties
other than the file name.

I also don't think that re-injection queue files directly into the
queue is a good idea.  Moving files back into the queue after
several days breaks more things than we discussed sofar.

For example, re-injected files will be past their expiration time.
This breaks another fundamental assumption of the queue file life
cycle, namely that there will be multiple delivery attempts before
a message expires. And you'd have the same problem with other MTAs.

If your infrastructure requires a review cycle, then it makes no
sense to keep that mail in the Postfix queue. The messages should
be given to a (web-based?) review system, and that system should
submit approved email via SMTP or /usr/sbin/sendmail to Postfix,
preserving the old contents and the old envelope sender/recipient.

Wietse

Re: smtp_sasl_mechanism_filter doesn't wok

[Patrick Ben Koetter]

* Zero Zeibov :
> I try to limit auth mech in postfix 2.6.1 on FreeBSD 6.4. For this
> I've added to main.conf:
> 
> smtp_sasl_mechanism_filter = plain, login

This does not apply to the SMTP server smtpd, but only to the SMTP client
smtp.

> But simple test by telnet shows following:
> 
> Connected to x.x.x.x.
> Escape character is '^]'.
> 220 xxx.xxx.com.ua ESMTP Postfix
> ehlo 1
> 250-xxx.xxx.com.ua
> 250-PIPELINING
> 250-SIZE 1024
> 250-ETRN
> 250-STARTTLS
> 250-AUTH NTLM LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5
> 250-AUTH=NTLM LOGIN PLAIN GSSAPI DIGEST-MD5 CRAM-MD5
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> 
> I also tried to limit auth mechs in /usr/local/lib/sasl2/smtpd.conf
> pwcheck_method: saslauthd
> mechlist: PLAIN LOGIN

The name of the parameter is "mech_list" not "mechlist".
Fix that first. 
If that doesn't do it all, create a symlink from /usr/lib/sasl2/ to
/usr/local/lib/sasl2/. This is what Cyrus SASL usually expects. Mileage on
FreeBSD might differ. I can't tell. I don't run FreeBSD.

p...@rick


> But it doesn't help.
> How I can remove such auth mechs as GSSAPI DIGEST-MD5 CRAM-MD5?

-- 
All technical answers asked privately will be automatically answered on
the list and archived for public access unless privacy is explicitely
required and justified.

saslfinger (debugging SMTP AUTH):

Re: log query

[LuKreme]

On 27-May-2009, at 05:29, Sahil Tandon wrote:

On Tue, 26 May 2009, LuKreme wrote:


On 26-May-2009, at 17:39, Lists wrote:

As part of my mail system I am using postgrey.

When stuff is stopped at the gate (so to speek) i.e. it doesn't even
get into the the system is there a log kept of this?


postgrey logs to the maillog. lines look like this:


I believe postgrey too logs to syslog's mail facility, so the file  
depends on
the system/configuration, and is probably not maillog on all  
platforms.


Which is why I said 'the maillog" and not /var/log/maillog or /var/log/ 
mail.log.


--
Yeah, Nick. Nick's the kinda guy you can trust. Nick's your buddy
Nick's the kinda guy you drink beers with. The kinda guy that
doesn't care if you puke in his car. Nick.

Re: log query

[Sahil Tandon]

On Wed, 27 May 2009, LuKreme wrote:

> On 27-May-2009, at 05:29, Sahil Tandon wrote:
>> On Tue, 26 May 2009, LuKreme wrote:
>>
>>> On 26-May-2009, at 17:39, Lists wrote:
 As part of my mail system I am using postgrey.

 When stuff is stopped at the gate (so to speek) i.e. it doesn't even
 get into the the system is there a log kept of this?
>>>
>>> postgrey logs to the maillog. lines look like this:
>>
>> I believe postgrey too logs to syslog's mail facility, so the file  
>> depends on
>> the system/configuration, and is probably not maillog on all  
>> platforms.
>
> Which is why I said 'the maillog" and not /var/log/maillog or /var/log/ 
> mail.log.

And my response states that 'the maillog' is not necessarily correct, but
let's not go off topic into a semantic debate.  Over and out.

-- 
Sahil Tandon 

myhostname is different between postconf and main.cf

[Tim Legg]

According to 'postconf -d', myhostname is set to genex.localdomain where genex 
is an arbitrary name I chose for a hostname when I installed Debian Lenny.

When I look in /etc/postfix/main.cf,
myhostname = genex.example1.com

Is this a normal discrepancy?

Is it even neccessary to have a hostname at all since the days of having 
seperate machines for seperate daemons are behind us for most websites?  After 
all, mail.example1.com, www.example1.com, pop3.example1.com,... are all the 
same machine these days.

Tim Legg


  

Re: myhostname is different between postconf and main.cf

[Ralf Hildebrandt]

* Tim Legg :
> 
> According to 'postconf -d',

Which displays the default, not what you set...

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
Wenn etwas Abstoßendes modern wird, ist es sofort anziehend.

Re: myhostname is different between postconf and main.cf

[Noel Jones]

Tim Legg wrote:

According to 'postconf -d', myhostname is set to genex.localdomain where genex 
is an arbitrary name I chose for a hostname when I installed Debian Lenny.

When I look in /etc/postfix/main.cf,
myhostname = genex.example1.com


postconf -d shows compiled-in defaults, not your settings. 
Use "postconf myhostname" to show the current setting as used 
by postfix.


Is it even neccessary to have a hostname 


Yes.


at all since the days of having seperate machines for seperate daemons are 
behind us for most websites?  After all, mail.example1.com, www.example1.com, 
pop3.example1.com,... are all the same machine these days.


Maybe in your shop... Postfix is used in a wide variety of 
environments, some of them have more than one computer.



  -- Noel Jones

Re: myhostname is different between postconf and main.cf

[Wietse Venema]

Tim Legg:
> 
> According to 'postconf -d', myhostname is set to genex.localdomain where g
>-enex is an arbitrary name I chose for a hostname when I installed Debian Len
>-ny.

As documented, "postconf -d" does not show what is in main.cf.

> When I look in /etc/postfix/main.cf,
> myhostname = genex.example1.com
> 
> Is this a normal discrepancy?

There is no discrepancy.

> Is it even neccessary to have a hostname at all since the days of having s
>-eperate machines for seperate daemons are behind us for most websites?  Afte
>-r all, mail.example1.com, www.example1.com, pop3.example1.com,... are all th
>-e same machine these days.

A machine name is required for several email-related Internet standards.
Besides, having all DNS names resolve to the same box is not normal usage.

Wietse

Re: virtual_alias_domains and virtual_maps

[mouss]

gabriele a écrit :
> Hi list !
> I run a python script which is a mail2news gateway for usenet postings.
> This script allows people without a proper usenet client to post to
> newsgroups by email client .
> The procedure is to write the interested newsgroups where to post to in
> the user part of the email address plus a date field like this:
> mail2news-mmdd-alt.test.newsgr...@m2n.mydomain .
> I have a main domain name mydomain.com and i have made a subdomain
> m2n.mydomain.com and i have included both in a virtual_alias_domains . I
> have configured also the vitual_maps 

this is obsolete. use virtual_alias_maps instead.

> with a catch-all domain entry like
> @m2n.mydomain  

catch-alls are a bad idea. better have the list of valid addresses.

> mail2news (user who owns the m2n python script) which is
> what i need for the above said user part for the mail2news gateway to
> work. I'm getting lots of mail bounced and 'user missing in virtual'
> maps and i needed some advices on ho to best implement the virtual
> aliases .

we need "evidence" because we can't guess why something that works for
many people doesn't work for you.

show relevant logs as well as output of 'postconf -n'. also, use postmap
-q to test your maps (to make sure lookups return the right values).

> Thanks
> 
> Gab

RE: How to safely re-inject an archived queue file?

[Curtis]

Terry:
> >
> > For those wondering why we can't just commit to only using the
> provided
> > utilities to manipulate queue files, it's because we are giving
> individual
> > users the ability to view messages that were placed in the hold queue
> and
> > release them up to 30 days after the messages were originally placed
> there.
> > While we could do this without moving the files out the hold queue,
> if we
> > were to leave them there, the number of files in the one directory
> would
> > cause us to take a performance hit all on it's own.
> 
> I do this right now with postsuper and postcat. It works fine although
> I
> haven't tried it on the scale you're talking about.
> 
> If the number of files/directory is an issue, hash_queue_depth should
> limit
> the number of files in a single directory.

Thanks for the tip on hash_queue_depth... I hadn't run into that feature
yet.  That would  have resolved my issue right there, except that then it
would be a tricky the quarantine system to figure out which messages it has
logged into it's database or not.

Right now it copies the messages out of the hold queue one by one and then
deletes them out of the hold queue with postsuper.  

Curtis

> 
> Terry
> 
> 
> 

Re: log query

[Lists]

LuKreme wrote:

On 26-May-2009, at 17:39, Lists wrote:

As part of my mail system I am using postgrey.

When stuff is stopped at the gate (so to speek) i.e. it doesn't even 
get into the the system is there a log kept of this?


postgrey logs to the maillog. lines look like this:

May 26 16:27:18 mail postgrey[949]: action=greylist, reason=new, 
client_name=n21z152l106.broadband.ctm.net, 
client_address=202.86.152.106, sender=ne...@netch.kiev.ua, 
recipient=krem...@kreme.com
May 26 20:39:53 mail postgrey[949]: action=pass, reason=triplet found, 
client_name=web59008.mail.re1.yahoo.com, client_address=66.196.101.4, 
sender=agogaz...m, recipient=keym



Hi yes thanks this is what I needed to know. We are having a problem 
with someone sending into us from a Microsoft Exchange 2007 server and I 
checked in my maillog file and couldn't see any information on the 
connection at all. So then I started to wonder if the system could 
reject it without notificiation.


Good to know that it does in-fact log.

Many thanks for all the responses.

Kate

RE: How to safely re-inject an archived queue file?

[Curtis]

Viktor:
> If the files are guaranteed to only have a single recipient at the
> point
> in your processing stream at which they are "held", you don't have to
> do
> anything nearly so complex. Just retain the file's original name and
> inode, by renaming it into a suitable directory tree in the same file-
> system.
> 
> Releasing can be accomplished by just moving it back into the maildrop
> queue
> with its original name.


Perfect... I didn't know it was safe to physically move the files out of a
queue directory.  We were copying them out and then deleting them from the
hold queue with postsuper.  Just moving the queue files would significantly
reduce disk i/o too. 


> A better design (working on this for our next gen quarantine) is I
> think
> to deliver the quarantined messages to a custom SMTP or LMTP agent that
> saves the message envelope and data in an ASCII form. Then messages
> released by users from the quarantine are re-injected also via SMTP.


I believe that is what Wietse is suggesting in his subsequent email.  It's
going to take a major overhall to get our quarantine system to be able to
accept submissions by SMTP/LMTP, but based on all that I'm hearing from
Wietse, I need to eventually make that happen.  

In the mean time, it seems like using doing "postsuper -r" to re-activate
old queue files would be a good alternative.  Hopefully that resolves the
expiration cycle issue that is caused when you inject a queue file directly
into the maildrop queue?
 
Curtis

Re: How to safely re-inject an archived queue file?

[Wietse Venema]

Curtis:
> In the mean time, it seems like using doing "postsuper -r" to re-activate
> old queue files would be a good alternative.  Hopefully that resolves the
> expiration cycle issue that is caused when you inject a queue file directly
> into the maildrop queue?

If that's "postsuper -r" from hold queue to maildrop queue, then
that will avoid the expiration problem. 

You'll want to run some tests with this. "postsuper -r" introduces
a rarely-used data path, and occasionally breaks after I add
something new to Postfix.

Wietse

Sender address rewrite

[Ausmus, Matt]

Hello all,

 

This is my first post.

 

I'm using postfix 2.3.3 on some Centos 5.x boxes strictly to send mail
for alerting purposes.  I've got relaying setup to go to our main smtp
server which is running FreeBSD 6.x and postfix.  What I'm trying to do
is for the outgoing messages to show the hostn...@chapman.edu so I can
look at the incoming message and know what box the alert is coming from.
The scripts I'm using are utilizing mailx to send the messages.

 

I setup sender_canonical and the address rewriting is working properly.
The problem that I'm having is that the mail is displayed in my mail
client as just root.  When I open the message it shows:

 

Root [hostn...@chapman.edu] or "root" 

 

Depending on the client.  I checked the header of the message and it
shows (this is an excerpt:  From: kennedydhcp...@chapman.edu (root)).
What I want to do is get rid of "Root[...]" and just have the rewritten
email address displayed in the mailbox list.  

 

How can I accomplish this?

 

Thanks.

 



Matt Ausmus

Network Administrator

Chapman University

635 West Palm Street

Orange, CA  92868

(714)628-2738

maus...@chapman.edu  

 

"Man will occasionally stumble over the truth, but most of the time he
will pick himself up and continue on."

- Churchill's Commentary on Man

Re: Sender address rewrite

[Wietse Venema]

Ausmus, Matt:
> Hello all,
>
> This is my first post.
>
> I'm using postfix 2.3.3 on some Centos 5.x boxes strictly to send mail
> for alerting purposes.  I've got relaying setup to go to our main smtp
> server which is running FreeBSD 6.x and postfix.  What I'm trying to do
> is for the outgoing messages to show the hostn...@chapman.edu so I can
> look at the incoming message and know what box the alert is coming from.
> The scripts I'm using are utilizing mailx to send the messages.
>
> I setup sender_canonical and the address rewriting is working properly.
> The problem that I'm having is that the mail is displayed in my mail
> client as just root.  When I open the message it shows:
>
> Root [hostn...@chapman.edu] or "root" 
>
> Depending on the client.  I checked the header of the message and it
> shows (this is an excerpt:  From: kennedydhcp...@chapman.edu (root)).
> What I want to do is get rid of "Root[...]" and just have the rewritten
> email address displayed in the mailbox list.
>
> How can I accomplish this?

You need to show what is in the email file itself, not what
the mail client is showing you.

Wietse