RE: Saving to Sent folder
Hi Everyone, Thanks for all the tips. Postfix and Dovecot are indeed on the same box and I do agree with you that it would require one heck of a hack to get this to work. Since this is software, it is possible, just maybe not with the current implementation of the 2 bits of software. It would be nice if postfix had some sort of setting to allow an external program to take a copy of the email being sent. Then, dovecot (again probably a hacked version) could store the email in the sent items folder. As for the BCC idea, this could work, but only if postfix was able to prefix the subject with something like [sent], or even better add a header, then dovecot can filter to the correct folder. Is this possible? Apart from my idea above, it looks like storing sent emails locally is the way to go
Re: Saving to Sent folder
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
Hi Everyone,
Thanks for all the tips.
Postfix and Dovecot are indeed on the same box and I do agree with you that
it would require one heck of a hack to get this to work.
See below, it might be a simple configuration still?
Since this is software, it is possible, just maybe not with the current
implementation of the 2 bits of software. It would be nice if postfix had
some sort of setting to allow an external program to take a copy of the
email being sent. Then, dovecot (again probably a hacked version) could
store the email in the sent items folder.
As for the BCC idea, this could work, but only if postfix was able to
prefix the subject with something like [sent], or even better add a
header, then dovecot can filter to the correct folder. Is this possible?
Can't you filter this on the from field?
Eg:
If from = my email then
{
store in sent items
} else {
store in inbox / parse other rules...
}
With that, I thought there is an option in postfix to bcc a single address on
all emails?
You could then put a filter like the following on all emails coming into that
address:
if from in list of local emails then
{
store in correct Sent Items
} else {
discard email as we don't want to duplicate incoming email
}
--
Joost
outbound sender
We have two postfix machines, one is a (weak) MX in/out gateway with amavisd+sa+clam that falls way behind during a huge (trusted) outbound send-only distribution list. The other, powerful postfix machine is not-yet-fully configged next-up to replace the current weak MX, but we can't do that, yet (waiting for sa 3.3.1). We can route all outbound mail through the powerful postfix box. How to set up the powerful outbound box with this sender-based routing: If listsen...@domain.tld, send to Internet Else, send to MX gateway thanks Len
Re: spamhaus dbl implementation
Ralf Hildebrandt put forth on 3/4/2010 1:55 AM: The Spamhaus DBL is a realtime database of domains (typically web site domains) found in spam messages. Mail server software capable of scanning email message body contents for URIs can use the DBL to identify, classify or reject spam containing DBL-listed domains. Two paragraphs later, on the same Spamhaus web page: The DBL is both a domain URI Blocklist and RHSBL. It is intended primarily for message body URI checks but it can additionally be used for connection checks at the SMTP level and header domain checks (HELO, connecting IP rDNS domain, From Reply-To domains, Message-ID domain) and other checks involving domains. So, can I use the following to reject connections whose A record is in the Spamhaus DBL? Does this also query for the domain in the PTR/FQrDNS record? smtpd_client_restrictions = ... reject_rhsbl_client dbl.spamhaus.org ... Thanks. -- Stan
Re: Saving to Sent folder
J. Roeleveld put forth on 3/4/2010 2:12 AM:
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
Hi Everyone,
Thanks for all the tips.
Postfix and Dovecot are indeed on the same box and I do agree with you that
it would require one heck of a hack to get this to work.
See below, it might be a simple configuration still?
Since this is software, it is possible, just maybe not with the current
implementation of the 2 bits of software. It would be nice if postfix had
some sort of setting to allow an external program to take a copy of the
email being sent. Then, dovecot (again probably a hacked version) could
store the email in the sent items folder.
As for the BCC idea, this could work, but only if postfix was able to
prefix the subject with something like [sent], or even better add a
header, then dovecot can filter to the correct folder. Is this possible?
Can't you filter this on the from field?
Eg:
If from = my email then
{
store in sent items
} else {
store in inbox / parse other rules...
}
With that, I thought there is an option in postfix to bcc a single address on
all emails?
You could then put a filter like the following on all emails coming into that
address:
if from in list of local emails then
{
store in correct Sent Items
} else {
discard email as we don't want to duplicate incoming email
}
Would sender_bcc_maps work if he uses Dovecot LDA/sieve? He could create a
sieve filter based on MAIL FROM: being his own address, and have sieve move
all such mails into his Sent Items folder. Might be worth a shot?
--
Stan
Re: outbound sender
Len Conrad put forth on 3/4/2010 4:16 AM: If listsen...@domain.tld, send to Internet Else, send to MX gateway This may be what you're looking for. http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps sender_dependent_relayhost_maps (default: empty) A sender-dependent override for the global relayhost parameter setting. The tables are searched by the envelope sender address and @domain. A lookup result of DUNNO terminates the search without overriding the global relayhost parameter setting (Postfix 2.6 and later). This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. For safety reasons, this feature does not allow $number substitutions in regular expression maps. This feature is available in Postfix 2.3 and later. -- Stan
Re: spamhaus dbl implementation
* Stan Hoeppner s...@hardwarefreak.com: Ralf Hildebrandt put forth on 3/4/2010 1:55 AM: The Spamhaus DBL is a realtime database of domains (typically web site domains) found in spam messages. Mail server software capable of scanning email message body contents for URIs can use the DBL to identify, classify or reject spam containing DBL-listed domains. Two paragraphs later, on the same Spamhaus web page: The DBL is both a domain URI Blocklist and RHSBL. It is intended primarily for message body URI checks but it can additionally be used for connection checks at the SMTP level and header domain checks (HELO, connecting IP rDNS domain, From Reply-To domains, Message-ID domain) and other checks involving domains. Oh wow :) So, can I use the following to reject connections whose A record is in the Spamhaus DBL? Does this also query for the domain in the PTR/FQrDNS record? smtpd_client_restrictions = ... reject_rhsbl_client dbl.spamhaus.org ... reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender dbl.spamhaus.org etc. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: Saving to Sent folder
On 2010-03-03 Stan Hoeppner wrote: Ansgar Wiechers put forth on 3/3/2010 9:01 AM: I was under the impression that his Postfix and Dovecot are running on the same (remote) host, and he's using Postfix as a smarthost for his outbound mail. If that's the case, then there certainly is an advantage, as his client won't have to transfer the message twice. Otherwise you're correct, of course. The point I was making is that the BCC'd copy is dropped in his inbox. Thus, when he opens his MUA, he still has to download the BCC'd sent items and move them to his IMAP sent items folder. So there's no net gain in IMAP traffic reduction. You're kidding, right? You certainly can't mean to imply that *not* having to transfer a large mail over the network via IMAP would be anything else than a significant reduction in IMAP traffic. I suppose it might be possible to hack together a solution in the MTA or IMAP server, manually dropping copies of sent messages in the user's IMAP Sent Items folder. That would be one heck of a kludge though. Not really. Use submission with a recipient_bcc_maps option and a sender_access map (or something) to add a custom header. Have the MDA store mails with that custom header in the sent items folder. Still a bit of a hack, but not as ugly as you make it sound. [...] My Dovecot server is local, 100BaseT, and it's still noticeably faster to store Sent Items locally on the workstation. Well, duh. Even old PATA/33 drives have almost three times the transfer rate of 100BaseT. Transfer rate isn't the issue, but latency. Local disk writes are buffered, whereas network writes via IMAP are not. You're talking nonsense. Of course transfer rate is exactly the issue at hand when we're talking about initially storing a large e-mail in a folder a) on a local disk or b) on a remote IMAP server. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Saving to Sent folder
On 2010-03-04 Ansgar Wiechers wrote: On 2010-03-03 Stan Hoeppner wrote: I suppose it might be possible to hack together a solution in the MTA or IMAP server, manually dropping copies of sent messages in the user's IMAP Sent Items folder. That would be one heck of a kludge though. Not really. Use submission with a recipient_bcc_maps option That would have to be sender_bcc_maps, of course. My mistake. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: outbound sender
If listsen...@domain.tld, send to Internet Else, send to MX gateway This may be what you're looking for. I read that before I sent my msg http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps sender_dependent_relayhost_maps (default: empty) A sender-dependent override for the global relayhost parameter setting. The tables are searched by the envelope sender address and @domain. A lookup result of DUNNO terminates the search without overriding the global relayhost parameter setting (Postfix 2.6 and later). This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. But we don't have a relayhost for the sender listsen...@domain.tld. We want that trusted sender to bypass the (scanning, weak) relayhost and nexthop to Internet. in the sender_dependent postfix box, relayhost = [mx.domain.tld] sender_dependent_relayhost_maps = sender_dependent_relayhost.map ... which would contain what, the null next hop? listsen...@domain.tld smtp: thanks Len
Re: Saving to Sent folder
On Thursday 04 March 2010 12:24:20 Stan Hoeppner wrote:
J. Roeleveld put forth on 3/4/2010 2:12 AM:
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
snipped non-relevant part
With that, I thought there is an option in postfix to bcc a single
address on all emails?
You could then put a filter like the following on all emails coming into
that address:
if from in list of local emails then
{
store in correct Sent Items
} else {
discard email as we don't want to duplicate incoming email
}
Would sender_bcc_maps work if he uses Dovecot LDA/sieve? He could create a
sieve filter based on MAIL FROM: being his own address, and have sieve move
all such mails into his Sent Items folder. Might be worth a shot?
This is how I would do it on my server, if I'd be so inclined :)
eg:
sender_bcc_maps = autosendfolderf...@mydomain.com
Then for the autosendfolderfill user set the following for the sieve-script:
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
You then need to make sure the autosendfolderfill user has permissions to
drop messages in the respective Sent folders.
I have not tested the above, but I think I'd be able to get this to work with
Postfix and Cyrus.
I am not familiar with Dovecot, but the above might be doable with Dovecot as
well.
--
Joost
Re: Saving to Sent folder
On 2010-03-03 4:49 PM, Ansgar Wiechers wrote: Read again. The sent items folder is in the user's mailbox, which Thunderbird most certainly does *not* access via SMTP, but via IMAP. My point was, if you want this to be done *without* TB having to save it to the Sent folder itself, it would essentially *have* to be done during the smtp transaction - there's simply no other way to do it. Saving a copy of sent mail is the MUA's job, not the MTA's. It is in most cases, yes (someone already pointed out that Exchange has the ability to save the Sent message without the client having to upload it again) - but again, my point is, why does it *have* to be that way. 'That's the way its done now', or 'that's the way it's always been done' is a stupid reason (by itself) to dismiss the idea of a potentially new feature. -- Best regards, Charles
Re: Anatomy of this simple spam.
On 3/3/2010 4:11 PM, Noel Jones wrote: You can't enforce the From: header. The From: header in your spam probably looked something like From: Word Word which is invalid, so postfix rewrote to From: w...@example.com w...@example.com Postfix rewriting controls are described here: http://www.postfix.org/ADDRESS_REWRITING_README.html#william Postfix doesn't normally rewrite headers in remote mail, but rewriting can still happen, such as if you have a content_filter. It may help to set in main.cf remote_header_rewrite_domain = domain.invalid to use @domain.invalid instead of your own domain in headers. http://www.postfix.org/postconf.5.html#remote_header_rewrite_domain -- Noel Jones That is exactly what is going on! Thanks everyone! Is such rewriting desirable in the general case? Or only when there is a specific need? Josh Kordani
Re: Saving to Sent folder
On Thursday 04 March 2010 14:55:59 you wrote:
12:24:20 Stan Hoeppner wrote:
J. Roeleveld put forth on 3/4/2010 2:12 AM:
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
snipped non-relevant part
With that, I thought there is an option in postfix to bcc a single
address on all emails?
You could then put a filter like the following on all emails coming
into that address:
if from in list of local emails then
{
store in correct Sent Items
} else {
discard email as we don't want to duplicate incoming email
}
Would sender_bcc_maps work if he uses Dovecot LDA/sieve? He could create
a sieve filter based on MAIL FROM: being his own address, and have sieve
move all such mails into his Sent Items folder. Might be worth a shot?
This is how I would do it on my server, if I'd be so inclined :)
eg:
sender_bcc_maps = autosendfolderf...@mydomain.com
Then for the autosendfolderfill user set the following for the
sieve-script:
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
You then need to make sure the autosendfolderfill user has permissions to
drop messages in the respective Sent folders.
I have not tested the above, but I think I'd be able to get this to work
with Postfix and Cyrus.
I am not familiar with Dovecot, but the above might be doable with Dovecot
as well.
--
Joost
---
---
-
Does that mean I'd need a autosendfolderfill for each user on the system?
First, please keep responses on the List to make it possible for other people
to find it with Google and also to allow other people to keep contributing.
As for your question:
No, you'll only need to create one of these users. The username doesn't
matter, as long as this user can have a filter set up and is allowed to post
messages into the Sent-folders of all the users.
You will need to create a filter-entry for each of your users, eg. duplicate
the following inside the filter for every user that is allowed to sent emails:
--
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
--
HTH,
Joost
RE: Saving to Sent folder
On Thursday 04 March 2010 14:55:59 you wrote:
12:24:20 Stan Hoeppner wrote:
J. Roeleveld put forth on 3/4/2010 2:12 AM:
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
snipped non-relevant part
With that, I thought there is an option in postfix to bcc a single
address on all emails?
You could then put a filter like the following on all emails coming
into that address:
if from in list of local emails then
{
store in correct Sent Items
} else {
discard email as we don't want to duplicate incoming email
}
Would sender_bcc_maps work if he uses Dovecot LDA/sieve? He could create
a sieve filter based on MAIL FROM: being his own address, and have sieve
move all such mails into his Sent Items folder. Might be worth a shot?
This is how I would do it on my server, if I'd be so inclined :)
eg:
sender_bcc_maps = autosendfolderf...@mydomain.com
Then for the autosendfolderfill user set the following for the
sieve-script:
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
You then need to make sure the autosendfolderfill user has permissions to
drop messages in the respective Sent folders.
I have not tested the above, but I think I'd be able to get this to work
with Postfix and Cyrus.
I am not familiar with Dovecot, but the above might be doable with Dovecot
as well.
--
Joost
---
---
-
Does that mean I'd need a autosendfolderfill for each user on the system?
First, please keep responses on the List to make it possible for other people
to find it with Google and also to allow other people to keep contributing.
As for your question:
No, you'll only need to create one of these users. The username doesn't
matter, as long as this user can have a filter set up and is allowed to post
messages into the Sent-folders of all the users.
You will need to create a filter-entry for each of your users, eg. duplicate
the following inside the filter for every user that is allowed to sent emails:
--
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
--
HTH,
Joost
Does this mean that mail received from the internet is also checked against
this filter?
Re: Saving to Sent folder
On 2010-03-04 Charles Marcus wrote: On 2010-03-03 4:49 PM, Ansgar Wiechers wrote: Read again. The sent items folder is in the user's mailbox, which Thunderbird most certainly does *not* access via SMTP, but via IMAP. My point was, if you want this to be done *without* TB having to save it to the Sent folder itself, it would essentially *have* to be done during the smtp transaction - there's simply no other way to do it. Which, if you carefully re-read the mail you initially replied to, is what I already wrote in the part that you chose to omit in your response. Saving a copy of sent mail is the MUA's job, not the MTA's. It is in most cases, yes (someone already pointed out that Exchange has the ability to save the Sent message without the client having to upload it again) Exchange is not an SMTP server, but a groupware server with an SMTP connector, and thus entirely different from SMTP servers like Postfix. but again, my point is, why does it *have* to be that way. Because SMTP servers do delivery up to a user's mailbox, and no further. SMTP servers do not have any knowledge about how a user may have organized his mailbox internally (i.e. concepts like sent mail folders and such), nor should they have to, as this isn't part of SMTP. If you want a groupware solution: there are quite a few around. Postfix (by itself), however, isn't one of them. 'That's the way its done now', or 'that's the way it's always been done' is a stupid reason (by itself) to dismiss the idea of a potentially new feature. See above. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: outbound sender
Len Conrad put forth on 3/4/2010 6:40 AM: But we don't have a relayhost for the sender listsen...@domain.tld. We want that trusted sender to bypass the (scanning, weak) relayhost and nexthop to Internet. in the sender_dependent postfix box, relayhost = [mx.domain.tld] sender_dependent_relayhost_maps = sender_dependent_relayhost.map ... which would contain what, the null next hop? listsen...@domain.tld smtp: It would be of the form listsen...@domain.tld smtp:10.1.2.3 10.1.2.3 being the new/big Postfix box you mentioned wanting to send this list mail through. But upon further reading, I'm not sure if you need that, or sender_dependent_default_transport_maps I'm pretty sure one of these two is what you need. One of the experts will jump in shortly with the definitive answer (I hope/assume). -- Stan
Re: Saving to Sent folder
On 2010-03-04 9:08 AM, J. Roeleveld wrote:
I am not familiar with Dovecot, but the above might be doable with
Dovecot as well.
Does that mean I'd need a autosendfolderfill for each user on the
system?
No, you'll only need to create one of these users. The username
doesn't matter, as long as this user can have a filter set up and is
allowed to post messages into the Sent-folders of all the users.
You will need to create a filter-entry for each of your users, eg.
duplicate the following inside the filter for every user that is
allowed to sent emails: --
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
Interesting... yes, this is doable with dovecot if you are using its
LDA, and you can do it via the global sieve script (which can be made
mandatory for all users) - no need to make a script for each user.
So... two more questions...
1. Can '-o sender_bcc_maps=hash:/etc/postfix/sender_bcc' be added to the
submission service in master.cf? If so, I think this could work.
2. What happens if the smtp send transaction fails? Would the message
still be bcc'd (hopefully not?)?
--
Best regards,
Charles
Re: Saving to Sent folder
On Thursday 04 March 2010 15:27:45 Jonathan Tripathy wrote:
On Thursday 04 March 2010 14:55:59 you wrote:
12:24:20 Stan Hoeppner wrote:
J. Roeleveld put forth on 3/4/2010 2:12 AM:
On Thursday 04 March 2010 08:57:30 Jonathan Tripathy wrote:
snipped non-relevant part
Does that mean I'd need a autosendfolderfill for each user on the system?
First, please keep responses on the List to make it possible for other
people to find it with Google and also to allow other people to keep
contributing.
As for your question:
No, you'll only need to create one of these users. The username doesn't
matter, as long as this user can have a filter set up and is allowed to
post messages into the Sent-folders of all the users.
You will need to create a filter-entry for each of your users, eg.
duplicate the following inside the filter for every user that is allowed
to sent emails: --
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
--
HTH,
Joost
---
-
Does this mean that mail received from the internet is also checked against
this filter?
Yes, unless you configure postfix to not apply the bcc configuration against
email originating from the internet.
I am not certain if this is possible, but if it isn't, this would be a usefull
additional feature.
Please check the documentation for Postfix to see how to do this.
--
Joost
Re: Saving to Sent folder
On Thursday 04 March 2010 16:10:21 Charles Marcus wrote:
On 2010-03-04 9:08 AM, J. Roeleveld wrote:
I am not familiar with Dovecot, but the above might be doable with
Dovecot as well.
Does that mean I'd need a autosendfolderfill for each user on the
system?
No, you'll only need to create one of these users. The username
doesn't matter, as long as this user can have a filter set up and is
allowed to post messages into the Sent-folders of all the users.
You will need to create a filter-entry for each of your users, eg.
duplicate the following inside the filter for every user that is
allowed to sent emails: --
if header :contains From m...@mydomain.com
{
fileinto me+Sent;
stop;
}
Interesting... yes, this is doable with dovecot if you are using its
LDA, and you can do it via the global sieve script (which can be made
mandatory for all users) - no need to make a script for each user.
My idea (NOTE: untested) would only require one dummy-account where this
filtering takes place.
The basic idea should be possible to be implemented with any filtering method
along with any mail-storage option you want.
The above is a bit more specific with Sieve-scripts, but I see no reason why
this approach wouldn't work with something like procmail
So... two more questions...
1. Can '-o sender_bcc_maps=hash:/etc/postfix/sender_bcc' be added to the
submission service in master.cf? If so, I think this could work.
I have no clue :)
As mentioned before, what I described is just the theory and I have no need to
implement this myself.
By putting this on the list, I am actually hoping for people who do know to
add their comments and perhaps get this written down as a working how-to
somewhere. (Add it to the postfix HOWTO-section?)
2. What happens if the smtp send transaction fails? Would the message
still be bcc'd (hopefully not?)?
I think this depends where the failure occurs.
If it occurs after the BCC-email is created, then the email still appears in
the sent-folder.
Btw, another option, which I saw described somewhere (can't remember where)
was to have the mail client store the email in a folder like: outbox and
then have a process on the server poll the outboxes for each user, send the
actual email and then move it to the sent folder when succesfully sent.
I think this method is closer to the way MS Exchange/MS Outlook works, but
this would, I think, require more work?
--
Joost
Re: Logging whitelisted mail
On 3/3/2010 11:57 PM, Stephen Carville wrote: Part of my configuration: smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination --- check_sender_access cidr:/etc/postfix/accept_by_ip Oops, check_sender_access uses the email address of the sender as the lookup key; this will never match an IP address. You should use check_client_access here instead. reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_sender_domain check_helo_access pcre:/etc/postfix/helo_check reject_unauth_pipelining --- check_sender_access hash:/etc/postfix/accept_by_domain reject_rbl_client zen.spamhaus.org check_sender_access cidr:/etc/postfix/reject_by_ip check_sender_access hash:/etc/postfix/reject_by_domain check_recipient_access hash:/etc/postfix/filtered_domains permit Is there a way to log when mail is accepted by the marked rules? The files have entries something like: 64.206.231.0/24 OK aacounty.org OK I include the reject_by_ip and reject_by_domain in a daily report and I've been asked about putting it how much mail was whitelisted. Postfix doesn't have any good way of logging accept actions. Really Ugly Hack: Instead of using OK as a result, use warn_if_reject reject, permit (note: OK won't work here, must be permit) This will log a message reject_warning: ... Access denied which may be somewhat confusing for a whitelist. Other choices are to use a policy server to do whitelisting and logging, or to modify the postfix source code. -- Noel Jones
Re: outbound sender
Len Conrad put forth on 3/4/2010 6:40 AM: But we don't have a relayhost for the sender listsen...@domain.tld. We want that trusted sender to bypass the (scanning, weak) relayhost and nexthop to Internet. in the sender_dependent postfix box, relayhost = [mx.domain.tld] sender_dependent_relayhost_maps = sender_dependent_relayhost.map ... which would contain what, the null next hop? listsen...@domain.tld smtp: It would be of the form listsen...@domain.tld smtp:10.1.2.3 10.1.2.3 being the new/big Postfix box you mentioned wanting to send this list mail through. That's precisely what I don't want to do. 1. all mail from inside goes to this (edge - 1 ) postfix box. 2. if from trusted/don't-scan-it listsen...@domain.tld, then don't go to edge/out-MX relayhost, resolve/send directly to Internet. 3. if not from listsen...@domain.tld, then send to relayhost. Len
Re: Saving to Sent folder
On 3/4/2010 9:26 AM, J. Roeleveld wrote: 1. Can '-o sender_bcc_maps=hash:/etc/postfix/sender_bcc' be added to the submission service in master.cf? If so, I think this could work. You can find which options are valid by reading the man page for each daemon. All the bcc functions are properties of the cleanup daemon, not smtpd. It's possible to define a separate cleanup service with sender_bcc_maps for submission. See the docs for adding an alternate cleanup service. 2. What happens if the smtp send transaction fails? Would the message still be bcc'd (hopefully not?)? The copy is created when postfix accepts the original message. -- Noel Jones
Re: Saving to Sent folder
On 2010-03-04 10:26 AM, J. Roeleveld wrote: Interesting... yes, this is doable with dovecot if you are using its LDA, and you can do it via the global sieve script (which can be made mandatory for all users) - no need to make a script for each user. My idea (NOTE: untested) would only require one dummy-account where this filtering takes place. Yes, but didn't you later say: You will need to create a filter-entry for each of your users, eg. duplicate the following inside the filter for every user that is allowed to sent emails: -- What I meant was, if you were using dovecots LDA, you wouldn't need to create these user scripts, the global script could handle it for everyone (using user variables, ie, %%Lu in this case)... The basic idea should be possible to be implemented with any filtering method along with any mail-storage option you want. The above is a bit more specific with Sieve-scripts, but I see no reason why this approach wouldn't work with something like procmail Correct... So... two more questions... These two questions weren't directed at you specifically, but in general to someone who actually knows the answers... ;) -- Best regards, Charles
Re: Saving to Sent folder
On Thursday 04 March 2010 16:57:02 Charles Marcus wrote: On 2010-03-04 10:26 AM, J. Roeleveld wrote: Interesting... yes, this is doable with dovecot if you are using its LDA, and you can do it via the global sieve script (which can be made mandatory for all users) - no need to make a script for each user. My idea (NOTE: untested) would only require one dummy-account where this filtering takes place. Yes, but didn't you later say: You will need to create a filter-entry for each of your users, eg. duplicate the following inside the filter for every user that is allowed to sent emails: -- What I meant was, if you were using dovecots LDA, you wouldn't need to create these user scripts, the global script could handle it for everyone (using user variables, ie, %%Lu in this case)... True, but it is my understanding, please correct me if I am wrong, that with Postfix, the BCC-option forces a copy of the email (regardless of which user sent it) to be delivered to a single email-address? This would, at least the way I see it, mean that the filtering only needs to be done by a single user (the owner of the bcc-email address). Eg: Email client | Postfix - external SMTP-server | BCC to bcc-user@mydomain | Postfix | filtering tool for user bcc-user | delivery into senders sent folder sender is determined by checking the mail-from header The basic idea should be possible to be implemented with any filtering method along with any mail-storage option you want. The above is a bit more specific with Sieve-scripts, but I see no reason why this approach wouldn't work with something like procmail Correct... So... two more questions... These two questions weren't directed at you specifically, but in general to someone who actually knows the answers... ;) True, but I tend to, when I at least have a theory, to also answer with my theory. I hope my reply made it clear that I was not 100% certain? :) -- Joost
Re: Logging whitelisted mail
On Thu, Mar 4, 2010 at 7:39 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 3/3/2010 11:57 PM, Stephen Carville wrote: Part of my configuration: smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination --- check_sender_access cidr:/etc/postfix/accept_by_ip Oops, check_sender_access uses the email address of the sender as the lookup key; this will never match an IP address. You should use check_client_access here instead. I didn't realize that. Thanks. Postfix doesn't have any good way of logging accept actions. Really Ugly Hack: Instead of using OK as a result, use warn_if_reject reject, permit (note: OK won't work here, must be permit) This will log a message reject_warning: ... Access denied which may be somewhat confusing for a whitelist. Other choices are to use a policy server to do whitelisting and logging, or to modify the postfix source code. Thank you. This is pretty much what I figured from reading the man pages. If it becomes a big deal I'll try your alternative or just hack a warning into the source code. -- Stephen Carville
Postfix doesn't fall back on other IP addresses
Hi, I noticed that Postfix doesn't fall back on other IP addresses associated with a certain MX-server when it fails to accept mail, but only uses the firs IP address it finds. If that fails, Postfix will move on to the next MX-server, but won't try any other available IP addresses for each of the MX-servers. This can be particularly troublesome for MX-servers with both IPv4 and IPv6 addresses, where Postfix will only use the IPv6 address (assuming postfix is configured with both IPv4 and IPv6 enabled), but won't fall back on the IPv4 address if IPv6 fails. For clarity, the setup I'm describing looks as follows: example.com. IN MX 10 mx1.example.com. example.com. IN MX 10 mx2.example.com. mx1.example.com. IN A some.IPv4.add.ress mx1.example.com. IN some:IPv6:add:ress mx2.example.com. IN A some.IPv4.add.ress mx2.example.com. IN some:IPv6:add:ress Postfix will try the IPv6-address of mx1, and if that fails it'll ignore the IPv4-address of mx1, but will skip to mx2 right away. It'll try the IPv6 address of mx2 and if that also fails, then this delivery attempt defers alltogether. If for some reason there is something wrong with IPv6 connectivity (which unfortunately appears to happen quite often now that IPv6 becomes more widely spread but people don't always quite understand it yet), then postfix won't be able to deliver mail at all because of this behaviour. As long as there is at least one IPv4-only MX-server, one wouldn't notice this behaviour. However as soon as you're being really good and equip all your MX-servers with IPv6 addresses, then all of a sudden postfix setups with broken IPv6 connectivity will stop delivering mail. In my humble opinion, it would be way better if postfix would only give up on an MX after it tried all available IP addresses. Or at the very least after trying at least one IPv4 and one IPv6 address, but I'd strongly prefer trying all available IP addresses before giving up. Any thoughts? Kind regards, Erik Logtenberg.
Re: order in cidr_table
192.168.1.0/24 DUNNO 192.168.2.3 REJECT blah 192.168.2.0/24 DUNNO 192.168.0.0/16 FILTER somefilter in short, create client based policies, not result based policies. The icing of the cake of two very helpful responses. Thanks both. Robert Lopez Unix Systems Administrator Central New Mexico Community College (CNM) 525 Buena Vista SE Albuquerque, New Mexico 87106
Re: Saving to Sent folder
On 2010-03-04 11:10 AM, J. Roeleveld wrote: True, but it is my understanding, please correct me if I am wrong, that with Postfix, the BCC-option forces a copy of the email (regardless of which user sent it) to be delivered to a single email-address? This would, at least the way I see it, mean that the filtering only needs to be done by a single user (the owner of the bcc-email address). Crap... my ignorance shines through... This won't work with your single address approach, because the sender address needs to be known by sieve, and with your way, it is not available. Doing this will require explicit sender_bcc_maps for each sender... not ideal, but still doable. Or... sender_bcc_maps can use a regex, so, could a relatively simple one-liner regex (simple for someone who understands them at least) be fashioned that would result in sender+s...@example.com? Or, is using regex for this a really bad idea? Most importantly, is any/all of this a bad idea? It seems like it should work reliably, and not add much overhead to the smtp transaction, but obviously I'm clueless when it comes to answering that with any degree of certainty... -- Best regards, Charles
Re: Saving to Sent folder
On 2010-03-04 10:48 AM, Noel Jones wrote: All the bcc functions are properties of the cleanup daemon, not smtpd. It's possible to define a separate cleanup service with sender_bcc_maps for submission. See the docs for adding an alternate cleanup service. Excellent - found this (before even reading your reply Noel), and found a reply from mouss back in 2007: with a single instance, edit master.cf to have something like this: submission ... smtpd ... -o cleanup_service_name=msa-cleanup msa-cleanup ... cleanup -o sender_bcc_maps=hash:/etc/postfix/msa_sender_bcc ... and remove all other references to sender_bcc_maps (in main.cf and master.cf). I think this is going to do exactly what I want... 2. What happens if the smtp send transaction fails? Would the message still be bcc'd (hopefully not?)? The copy is created when postfix accepts the original message. That's what I was assuming/hoping, but I've burned myself enough times simply by not asking the question... Now the only other question remaining is whether or not it is advisable to use a regex for the sender_bcc_maps to avoid the necessity of maintaining an explicit map for all users... -- Best regards, Charles
Re: Saving to Sent folder
On Thursday 04 March 2010 18:23:19 Charles Marcus wrote: On 2010-03-04 11:10 AM, J. Roeleveld wrote: True, but it is my understanding, please correct me if I am wrong, that with Postfix, the BCC-option forces a copy of the email (regardless of which user sent it) to be delivered to a single email-address? This would, at least the way I see it, mean that the filtering only needs to be done by a single user (the owner of the bcc-email address). Crap... my ignorance shines through... All wisdom starts with admitting your ignorance (Not sure who originally said that :) ) This won't work with your single address approach, because the sender address needs to be known by sieve, and with your way, it is not available. Doing this will require explicit sender_bcc_maps for each sender... not ideal, but still doable. Or... This is why I said you'd need to add a filter for each local user, dumping the email into each users Sent-folder. sender_bcc_maps can use a regex, so, could a relatively simple one-liner regex (simple for someone who understands them at least) be fashioned that would result in sender+s...@example.com? Or, is using regex for this a really bad idea? I think a regex would make more sense when dealing with a lot of users. As otherwise you'd be forced to make a manual entry for all your (100+?) users. But, unless you can apply this only for outgoing emails, this will lead to a lot of wrong emails being sent for external emails. Not sure if I make my point clear here. Lets say charlie and maria are emailing with each other. (And we have this setup working) charlie is using this email-server and has email: char...@local.com maria, working for a different company, has email: ma...@remote.com Now, when charlie sends maria an email, Postfix at local.com will send the email to ma...@remote.com and also, through the mentioned magic, put a copy of the email into charlie's Sent folder. Now, when Maria then replies, we need to make sure that the Postfix at local.com will only forward the email to Charlie's Inbox and not try to deliver a copy into Maria's Sent folder. (Which could exist if Charlie has a colleague with the same name) (Disclaimer: The names in this story are fictional, and bla bla bla :) ) Most importantly, is any/all of this a bad idea? It seems like it should work reliably, and not add much overhead to the smtp transaction, but obviously I'm clueless when it comes to answering that with any degree of certainty... As far as I can tell, it would double the amount of emails being handled by Postfix. To reduce the overhead, the bcc-option should only be done for out-going email. Not for incoming. This would also then resolve the problem with Charlie and Maria as mentioned above. -- Joost
Re: Saving to Sent folder
On 3/4/2010 11:26 AM, Charles Marcus wrote: Now the only other question remaining is whether or not it is advisable to use a regex for the sender_bcc_maps to avoid the necessity of maintaining an explicit map for all users... Yes. Using a regexp with *_bcc_maps has been discussed in the past as a way to retain the original sender. Off the top of my head, maybe something like: if /@example\.com$/ /^...@.*$/ archive+$1...@example.com endif Search the archives for more detailed discussions about mail archiving, and probably better examples. -- Noel Jones
Re: Saving to Sent folder
On 2010-03-04 1:19 PM, Noel Jones wrote: On 3/4/2010 11:26 AM, Charles Marcus wrote: Now the only other question remaining is whether or not it is advisable to use a regex for the sender_bcc_maps to avoid the necessity of maintaining an explicit map for all users... Yes. Using a regexp with *_bcc_maps has been discussed in the past as a way to retain the original sender. Off the top of my head, maybe something like: if /@example\.com$/ /^...@.*$/ archive+$1...@example.com endif Search the archives for more detailed discussions about mail archiving, and probably better examples. Awesome... many thanks Noel! -- Best regards, Charles
Postfix Book
What happened to the Ralf and Patrick Book of Postfix book that seems to be out of print? Is there another edition scheduled or was the market just not large enough to keep the book in print? Is there another Postfix book recommended by the group? Thanks.
Re: Postfix Book
On 3/4/2010 1:42 PM, Leonard Jacobs wrote: What happened to the Ralf and Patrick Book of Postfix book that seems to be out of print? Is there another edition scheduled or was the market just not large enough to keep the book in print? Is there another Postfix book recommended by the group? From the recent archives: http://archives.neohapsis.com/archives/postfix/2010-01/0891.html
postfix gmail.smtp.com -port 587
hey new to configuring postfix, got a few questions
Re: postfix gmail.smtp.com -port 587
On Thursday 04 March 2010 20:10:26 bruce wrote: hey new to configuring postfix, got a few questions If you ask them, we can try to provide some answers?
Dual Transports
I have been looking through archives and through the man pages and thought I'd go ahead and post my question. My situation is this: I need to deliver mail coming in addressed to a specific domain to two separate transports. There are no mailboxes local to the server at all. However, I did not think it was possible to configure two separate transports in this manner. Our server is acting as a scanning gateway and passes the message on after performing this task. I then began to look at possibly using recipient_bcc_maps. My question though is that if I am needing to deliver the same address to two individual external systems, wouldn't I still need to define a 2nd transport to get messages to the 2nd server. Would I need to rewrite the domain on the bcc and setup a 2nd MX for the rewritten domain? The end goal is to have messages coming in to any address @mydomain.com delivered to server1 and server2 with the original address intact after processing. Any thoughts on ways to handle this would be appreciated. Clay
postfix gmail.smtp.com -port 587
hey new to configuring postfix, got a few questions about how to configure postfix. I'm running Centos/Fedora, with Postfix, from the basic yum install. The Sendmail process has been stopped. I can easily send a basic test mail from the cmdline. Ie: mail f...@gmail.com subject: blah test . Cc: works with no issue. However, the email on the gmail end, is in the Spam folder, which is to be expected. As I understand the different articles I've seen, Postfix can be configured to allow me to authenticate emails, to in effect, relay/send them using the authenticaion of a valid email user/passwd from a valid gmail account. (or from my own isp user/passwd). I've seen a great deal of online articles, but I'm still confused as to exactly what's required to make this happen. i know that the main.cf, as well as the transports/sasl-passwd files have to be modified. I'm confused as to whether certs are actually required, or if TSL is/is not required So, I'm trying to figure out exactly what config files have to be modified, as well as what has to be inserted in the config files. If I could see the confi files from someone who's actually gone through this process, I could more quickly get my head around what I've screwed up! Thanks
PATCH reject_rhsbl_reverse_client
This patch adds a reject_rhsbl_reverse_client function that
uses the unverified client hostname for the RBL lookup.
The idea is that this might increase rhsbl hit rates if the
hostname is more frequently available. On the other hand,
spam-only domains seem to usually have verifiable hostnames,
so I'm not sure how much this will really help.
This seems to work, but the usual disclaimers apply.
Comments welcome.
-- Noel Jones
*** src/global/mail_params.hSun Jan 17 14:54:35 2010
--- /tmp/tmp/mail_params.h Thu Mar 4 13:31:35 2010
***
*** 2124,2129
--- 2124,2130
#define REJECT_RBLreject_rbl/* LaMont compatibility */
#define REJECT_RBL_CLIENT reject_rbl_client
#define REJECT_RHSBL_CLIENT reject_rhsbl_client
+ #define REJECT_RHSBL_REVERSE_CLIENT reject_rhsbl_reverse_client
#define REJECT_RHSBL_HELO reject_rhsbl_helo
#define REJECT_RHSBL_SENDER reject_rhsbl_sender
#define REJECT_RHSBL_RECIPIENTreject_rhsbl_recipient
*** src/smtpd/smtpd_check.c Thu Nov 5 13:09:43 2009
--- /tmp/tmp/smtpd_check.c Thu Mar 4 13:45:53 2010
***
*** 3690,3695
--- 3690,3705
status = reject_rbl_domain(state, *cpp, state-name,
SMTPD_NAME_CLIENT);
}
+ } else if (strcasecmp(name, REJECT_RHSBL_REVERSE_CLIENT) == 0) {
+ if (cpp[1] == 0)
+ msg_warn(restriction %s requires domain name argument,
+name);
+ else {
+ cpp += 1;
+ if (strcasecmp(state-name, unknown) != 0)
+ status = reject_rbl_domain(state, *cpp, state-reverse_name,
+ SMTPD_NAME_REV_CLIENT);
+ }
} else if (is_map_command(state, name, CHECK_CCERT_ACL, cpp)) {
status = check_ccert_access(state, *cpp, def_acl);
} else if (is_map_command(state, name, CHECK_CLIENT_NS_ACL, cpp)) {
*** proto/postconf.protoWed Feb 10 09:18:39 2010
--- /tmp/tmp/postconf.proto Thu Mar 4 13:58:07 2010
***
*** 2594,2600
p
The numerical Postfix SMTP server response code when a remote SMTP
client request is blocked by the reject_rbl_client, reject_rhsbl_client,
! reject_rhsbl_sender or reject_rhsbl_recipient restriction.
/p
p
--- 2594,2601
p
The numerical Postfix SMTP server response code when a remote SMTP
client request is blocked by the reject_rbl_client, reject_rhsbl_client,
! reject_rhsbl_reverse_client, reject_rhsbl_sender or
! reject_rhsbl_recipient restriction.
/p
p
***
*** 4889,4894
--- 4890,4905
any A record under irbl_domain/i. See the reject_rbl_client
description above for additional RBL related configuration parameters.
This feature is available in Postfix 2.0 and later. /dd
+
+ dtba name=reject_rhsbl_reverse_clientreject_rhsbl_reverse_client
irbl_domain=d.d.d.d/i/a/b/dt
+
+ ddReject the request when the unverified reverse client hostname
+ is listed with the A record id.d.d.d/i under irbl_domain/i
+ (Postfix version 2.1 and later only). If no i=d.d.d.d/i is
+ specified, reject the request when the unverified reverse client hostname
+ is listed with any A record under irbl_domain/i. See the reject_rbl_client
+ description above for additional RBL related configuration parameters.
+ This feature is available in Postfix 2.8 and later. /dd
dtba
name=reject_unknown_client_hostnamereject_unknown_client_hostname/a/b
(with Postfix lt; 2.3: reject_unknown_client)/dt
*** src/smtpd/smtpd.c Thu Mar 4 14:08:24 2010
--- /tmp/tmp/smtpd.cThu Mar 4 14:21:46 2010
***
*** 797,803
/* .IP \fBmaps_rbl_reject_code (554)\fR
/*The numerical Postfix SMTP server response code when a remote SMTP
/*client request is blocked by the reject_rbl_client, reject_rhsbl_client,
! /*reject_rhsbl_sender or reject_rhsbl_recipient restriction.
/* .IP \fBnon_fqdn_reject_code (504)\fR
/*The numerical Postfix SMTP server reply code when a client request
/*is rejected by the reject_non_fqdn_helo_hostname, reject_non_fqdn_sender
--- 797,804
/* .IP \fBmaps_rbl_reject_code (554)\fR
/*The numerical Postfix SMTP server response code when a remote SMTP
/*client request is blocked by the reject_rbl_client, reject_rhsbl_client,
! /*reject_rhsbl_reverse_client, reject_rhsbl_sender or
reject_rhsbl_recipient
! /*restriction.
/* .IP \fBnon_fqdn_reject_code (504)\fR
/*The numerical Postfix SMTP server reply code when a client request
/*is rejected by the reject_non_fqdn_helo_hostname, reject_non_fqdn_sender
Re: PATCH reject_rhsbl_reverse_client
Noel Jones: This patch adds a reject_rhsbl_reverse_client function that uses the unverified client hostname for the RBL lookup. The idea is that this might increase rhsbl hit rates if the hostname is more frequently available. On the other hand, spam-only domains seem to usually have verifiable hostnames, so I'm not sure how much this will really help. This seems to work, but the usual disclaimers apply. Comments welcome. Looks OK. At this point in the code we don't have to worry that the hostname is a smoking pile of radioactive waste. Postfix's name lookup routine has verified that the name satisfies the applicable RFC requirements for syntax and size. Wietse
Re: Postfix doesn't fall back on other IP addresses
Erik Logtenberg: Hi, I noticed that Postfix doesn't fall back on other IP addresses associated with a certain MX-server when it fails to accept mail, but only uses the firs IP address it finds. If that fails, Postfix will move on to the next MX-server, but won't try any other available IP addresses for each of the MX-servers. Do show concrete evidence, please, as requested in the mailing list welcome message. As distributed by me, Postfix tries up to $smtp_mx_address_limit (default: 5) server IP addresses, and it stops after $smtp_mx_session_limit (default: 2) SMTP sessions. Note: that is five IP addresses and two sessions. Of course it is possible that some distributor modifies Postfix to enforce their personal preferences on all users, but that is not my problem. We still have a choice of operating systems. Wietse
Re: Dual Transports
On 3/4/2010 1:26 PM, Clayton Keller wrote: I have been looking through archives and through the man pages and thought I'd go ahead and post my question. My situation is this: I need to deliver mail coming in addressed to a specific domain to two separate transports. There are no mailboxes local to the server at all. However, I did not think it was possible to configure two separate transports in this manner. Our server is acting as a scanning gateway and passes the message on after performing this task. I then began to look at possibly using recipient_bcc_maps. My question though is that if I am needing to deliver the same address to two individual external systems, wouldn't I still need to define a 2nd transport to get messages to the 2nd server. Would I need to rewrite the domain on the bcc and setup a 2nd MX for the rewritten domain? The end goal is to have messages coming in to any address @mydomain.com delivered to server1 and server2 with the original address intact after processing. Any thoughts on ways to handle this would be appreciated. Clay To deliver to two destinations, you need two recipients. You can use a regexp recipient_bcc_maps to add another recipient, then use smtp_generic_maps to rewrite it back to the original during delivery. Use a transport_maps entry to direct the bcc'ed mail to the proper server. # main.cf recipient_bcc_maps = regexp:/etc/postfix/recipient_bcc smtp_generic_maps = hash:/etc/postfix/smtp_generic transport_maps = hash:/etc/postfix/transport # recipient_bcc if /@example\.com/ /^...@example\.com$/ $...@new.example.com endif # smtp_generic @new.example.com @example.com # transport new.example.com smtp:new.server.example.com Be sure to postmap the hash: tables after making changes to them. -- Noel Jones
getting loops on multi-instance configuration
Hi all. Im getting a loop in my postfix-multi configuration, and cant see what is wrong. I try to follow the README [1] as close as i could. Here is a sample of /var/log/mail after a email is received: Mar 4 18:43:28 vmailmulti postfix-in/smtpd[28733]: connect from mail.fmed.uba.ar[157.92.152.1] Mar 4 18:43:28 vmailmulti postfix-in/smtpd[28733]: 4DD09D81D1: client=mail.fmed.uba.ar[157.92.152.1] Mar 4 18:43:28 vmailmulti postfix-in/cleanup[28735]: 4DD09D81D1: message-id=4b902860.6060...@fmed.uba.ar Mar 4 18:43:28 vmailmulti postfix-in/qmgr[28731]: 4DD09D81D1: from=gher...@fmed.uba.ar, size=726, nrcpt=1 (ueue active) Mar 4 18:43:28 vmailmulti postfix-in/smtpd[28733]: disconnect from mail.fmed.uba.ar[157.92.152.1] Mar 4 18:43:32 vmailmulti postfix-out/smtpd[28737]: connect from localhost[127.0.0.1] Mar 4 18:43:32 vmailmulti postfix-out/smtpd[28737]: 9EFA2D81D2: client=mail.fmed.uba.ar[157.92.152.1] Mar 4 18:43:32 vmailmulti postfix-out/cleanup[28739]: 9EFA2D81D2: message-id=4b902860.6060...@fmed.uba.ar Mar 4 18:43:32 vmailmulti postfix-out/smtpd[28737]: disconnect from localhost[127.0.0.1] Mar 4 18:43:32 vmailmulti postfix-out/qmgr[28668]: 9EFA2D81D2: from=gher...@fmed.uba.ar, size=1398, nrcpt=1(queue active) Mar 4 18:43:32 vmailmulti postfix-in/smtpd[28733]: connect from unknown[157.92.152.62] Mar 4 18:43:32 vmailmulti postfix-in/smtpd[28733]: AA33AD81D3: client=unknown[157.92.152.62] Mar 4 18:43:32 vmailmulti postfix-in/cleanup[28735]: AA33AD81D3: message-id=4b902860.6060...@fmed.uba.ar Mar 4 18:43:32 vmailmulti amavis[28480]: (28480-04) Passed SPAMMY, [157.92.152.1] [157.92.152.105] gher...@fed.uba.ar - gher...@vmail.fmed.uba.ar, Message-ID: 4b902860.6060...@fmed.uba.ar, mail_id: x6Po8fRtlSTq, its: 6.333, size: 726, queued_as: 9EFA2D81D2, 4351 ms Mar 4 18:43:32 vmailmulti postfix-in/smtp[28736]: 4DD09D81D1: to=gher...@vmail.fmed.uba.ar, relay=127.0.0.1127.0.0.1]:10025, delay=4.4, delays=0.03/0.01/0/4.4, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=28480-04, from MA([127.0.0.1]:10026): 250 2.0.0 Ok: queued as 9EFA2D81D2) Mar 4 18:43:32 vmailmulti postfix-in/qmgr[28731]: 4DD09D81D1: removed Mar 4 18:43:32 vmailmulti postfix-in/smtpd[28733]: disconnect from unknown[157.92.152.62] Mar 4 18:43:32 vmailmulti postfix-in/qmgr[28731]: AA33AD81D3: from=gher...@fmed.uba.ar, size=1599, nrcpt=1 queue active) Mar 4 18:43:32 vmailmulti postfix-out/smtp[28740]: 9EFA2D81D2: to=gher...@vmail.fmed.uba.ar, relay=vmail.fmd.uba.ar[157.92.152.62]:25, delay=0.08, delays=0.04/0.01/0/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued s AA33AD81D3) Mar 4 18:43:32 vmailmulti postfix-out/qmgr[28668]: 9EFA2D81D2: removed Mar 4 18:43:36 vmailmulti postfix-out/smtpd[28737]: connect from localhost[127.0.0.1] Mar 4 18:43:36 vmailmulti postfix-out/smtpd[28737]: B8EEED81D1: client=unknown[157.92.152.62] Mar 4 18:43:36 vmailmulti postfix-out/cleanup[28739]: B8EEED81D1: message-id=4b902860.6060...@fmed.uba.ar Mar 4 18:43:36 vmailmulti postfix-out/smtpd[28737]: disconnect from localhost[127.0.0.1] Mar 4 18:43:36 vmailmulti postfix-out/qmgr[28668]: B8EEED81D1: from=gher...@fmed.uba.ar, size=2097, nrcpt=1(queue active So, the email comes to postfix-in, it send trough amavis, and later a new (repeated) mail appear. It never goes to the central hub. Eventualy, i get Mar 4 18:48:17 vmailmulti postfix-out/smtp[28770]: 80A9AD814C: to=gher...@vmail.fmed.uba.ar, relay=vmail.fmed.uba.ar[157.92.152.62]:25, delay=385, delays=385/0.01/0.01/0.02, dsn=4.4.0, status=deferred (host vmail.fmed.uba.ar[157.92.152.62] said: 454 4.4.0 Error: too many hops (in reply to end of DATA command)) Here is my config files: /etc/postfix-in/main.cf soft_bounce = yes queue_directory = /var/spool/postfix-in command_directory = /usr/sbin daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix-in mail_owner = postfix inet_interfaces = all mydestination = local_recipient_maps = unknown_local_recipient_reject_code = 550 alias_maps = alias_database = debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id sleep 5 sendmail_path = /usr/sbin/sendmail newaliases_path = /usr/bin/newaliases mailq_path = /usr/bin/mailq setgid_group = maildrop html_directory = /usr/share/doc/packages/postfix-doc/html manpage_directory = /usr/share/man sample_directory = /usr/share/doc/packages/postfix-doc/samples readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES master_service_disable = authorized_submit_users = root multi_instance_group = mta multi_instance_name = postfix-in local_transport = error:5.1.1 Mailbox unavaiable local_header_rewrite_clients = default_transport = smtp:[127.0.0.1]:10025 relay_transport = $default_transport virtual_transport = $default_transport smtp_send_xforward_command = yes smtp_destination_recipient_limit = 1000 smtp_data_done_timeout = 1200s smtpd_client_port_logging = no multi_instance_enable = yes
Re: Dual Transports
On 3/4/2010 3:54 PM, Noel Jones wrote: On 3/4/2010 1:26 PM, Clayton Keller wrote: I have been looking through archives and through the man pages and thought I'd go ahead and post my question. My situation is this: I need to deliver mail coming in addressed to a specific domain to two separate transports. There are no mailboxes local to the server at all. However, I did not think it was possible to configure two separate transports in this manner. Our server is acting as a scanning gateway and passes the message on after performing this task. I then began to look at possibly using recipient_bcc_maps. My question though is that if I am needing to deliver the same address to two individual external systems, wouldn't I still need to define a 2nd transport to get messages to the 2nd server. Would I need to rewrite the domain on the bcc and setup a 2nd MX for the rewritten domain? The end goal is to have messages coming in to any address @mydomain.com delivered to server1 and server2 with the original address intact after processing. Any thoughts on ways to handle this would be appreciated. Clay To deliver to two destinations, you need two recipients. You can use a regexp recipient_bcc_maps to add another recipient, then use smtp_generic_maps to rewrite it back to the original during delivery. Use a transport_maps entry to direct the bcc'ed mail to the proper server. # main.cf recipient_bcc_maps = regexp:/etc/postfix/recipient_bcc smtp_generic_maps = hash:/etc/postfix/smtp_generic transport_maps = hash:/etc/postfix/transport # recipient_bcc if /@example\.com/ /^...@example\.com$/ $...@new.example.com endif # smtp_generic @new.example.com @example.com # transport new.example.com smtp:new.server.example.com Be sure to postmap the hash: tables after making changes to them. -- Noel Jones Noel, Thank you. That's the direction I was thinking, but the part that was eluding me was the smtp_generic portion, I was looking for rewrite but had not stumbled on that aspect you recommended just yet. I will take these ideas and work my own tests out from them. Thanks again.
Re: Postfix doesn't fall back on other IP addresses
Hi Wietse, Ah, seems you were right after all: most bugs are indeed solved by reading the manual ;) Anyway, I think now I understand what's going on. The distribution that I use (Fedora 12) left those two settings to their default. In this specific case the setting of 5 IP's just isn't high enough, since this host has 22 IP addresses, 11 of which are IPv6. So after trying the first 5 (all IPv6), postfix hasn't tried any IPv4 address yet. I see in the documentation that I can actually disable this limitation. Is there a good reason why I shouldn't want to do this? Any kind of denial of service attack that disabling this limit would make possible? Kind regards, Erik. On 03/04/2010 10:27 PM, Wietse Venema wrote: Erik Logtenberg: Hi, I noticed that Postfix doesn't fall back on other IP addresses associated with a certain MX-server when it fails to accept mail, but only uses the firs IP address it finds. If that fails, Postfix will move on to the next MX-server, but won't try any other available IP addresses for each of the MX-servers. Do show concrete evidence, please, as requested in the mailing list welcome message. As distributed by me, Postfix tries up to $smtp_mx_address_limit (default: 5) server IP addresses, and it stops after $smtp_mx_session_limit (default: 2) SMTP sessions. Note: that is five IP addresses and two sessions. Of course it is possible that some distributor modifies Postfix to enforce their personal preferences on all users, but that is not my problem. We still have a choice of operating systems. Wietse
Re: Postfix doesn't fall back on other IP addresses
On Thu, Mar 04, 2010 at 11:10:37PM +0100, Erik Logtenberg wrote: Anyway, I think now I understand what's going on. The distribution that I use (Fedora 12) left those two settings to their default. In this specific case the setting of 5 IP's just isn't high enough, since this host has 22 IP addresses, 11 of which are IPv6. So after trying the first 5 (all IPv6), postfix hasn't tried any IPv4 address yet. If your system has no useful IPv6 connectivity, disable IPv6 in Postfix. http://www.postfix.org/inet_protocols -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
Re: getting loops on multi-instance configuration
On Thu, Mar 04, 2010 at 06:54:56PM -0300, Gerardo Herzig wrote: Hi all. Im getting a loop in my postfix-multi configuration, and cant see what is wrong. I try to follow the README [1] as close as i could. You need a transport table on the output Postfix to direct mail for suitable domains to the internal mail hub. You can also use virtual rewriting to rewrite to an internal domain, which has internal MX records, or still a transport table entry. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
SMTP AUTH not subjected to unnecessary check?
I have Postfix with SMTP AUTH with self issued certificate, it all works well (as long as I don't touch it..) I have now allowed some users to use SMTP AUTH, but, some of their mail then gets evaluated as 'spam' by amavisd/spamassasin scores, amongst these, 'dynamic ip' type scores am I correctly exempting SMTP AUTH users from unnecessary anti-spam evals such as 'dynamic ip' 'direct access to smpt host' type of evals ? or is this something I need to in amavisd/spamassasin ? in other words, is my postfix setup correct ? and, optimal ? thanks --- postconf -n (my network obfuscated as 111.222.yyy.xxx) address_verify_sender = $double_bounce_sender alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases body_checks = pcre:/etc/postfix/body_checks body_checks_size_limit = 15 broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes header_checks = pcre:/etc/postfix/header_checks home_mailbox = Maildir/ html_directory = /usr/share/doc/postfix-2.4.5-documentation/html local_recipient_maps = unix:passwd.byname $alias_maps local_transport = local mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 1024 mime_header_checks = pcre:$config_directory/mime_headers.pcre mydestination = $myhostname, localhost.$mydomain mynetworks = 111.222.yyy.xxx 127.0.0.1 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.4.5-documentation/readme recipient_delimiter = + sample_directory = /etc/postfix/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_tls_loglevel = 1 smtp_tls_note_starttls_offer = yes smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/spool/postfix/smtp_tls_session_cache smtp_tls_session_cache_timeout = 3600s smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access hash:/etc/postfix/pop-before-smtp, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_no_checks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_sender_domain, reject_unknown_reverse_client_hostname reject_unlisted_recipient, check_sender_access hash:/etc/postfix/freemail_access, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, reject_rbl_client zen.spamhaus.org, reject_rbl_client combined.njabl.org, reject_rbl_client bl.spamcop.net, reject_rhsbl_sender dsn.rfc-ignorant.org, reject_rbl_client korea.services.net, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client psbl.surriel.com, check_policy_service inet:127.0.0.1:10031, permit smtpd_restriction_classes = from_freemail_host smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/postfix/tls/cacert.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/tls/smtpd.crt smtpd_tls_key_file = /etc/postfix/tls/smtpd.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_session_cache smtpd_tls_session_cache_timeout = 36000s strict_rfc821_envelopes = yes tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid_maps = static:5000 virtual_mailbox_base = /var/mail/vhosts virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_limit = 1024 virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 5000 virtual_transport = virtual virtual_uid_maps = static:5000 -- Voytek
Re: Postfix doesn't fall back on other IP addresses
If your system has no useful IPv6 connectivity, disable IPv6 in Postfix. http://www.postfix.org/inet_protocols The issue is that other people with broken IPv6 connectivity have trouble delivering mail to me, because my mailservers have many different IP addresses, both IPv4 and IPv6. Due to the default of a maximum of 5 IP addresses being tried before giving up, combined with the fact that IPv6 apparently has precedence over IPv4, no one with broken IPv6 can deliver mail to me when I have = 5 IPv6 addresses configured. Thank you for your tip nevertheless, if everyone would follow it, this problem wouldn't exist.
Re: Postfix doesn't fall back on other IP addresses
People who configure MX records should read the SMTP RFC, in particular section 5. Address Resolution and Mail Handling. By design, Postfix enforces sane limits on ALL information. In the case of SMTP server IP addresses. Such limits protect Postfix against abusive sites. Thank you again for your reply, Wietse. Please forgive my relative cluelessness regarding this issue, but could you please elaborate a bit on what you mean? I just read section 5 of RFC 2821, and section 4.5.4.1 (Sending Strategy) as well, which is referenced to in section 5. I understand that the question of whether or not a sender should try different IP's on a multihomed host has been controversial. However by pointing to this RFC you seem to imply more that the MX records aren't configured right to begin with, at least not according to best practice / common sense. Do I interpret you correctly? If so, what would you consider the best way to configure MX records, given the situation that there are 11 incoming SMTP servers required to handle the load and they all have both an IPv4 and an IPv6 address?
Re: Anatomy of this simple spam.
Joshua Kordani a écrit : On 3/3/2010 4:11 PM, Noel Jones wrote: You can't enforce the From: header. The From: header in your spam probably looked something like From: Word Word which is invalid, so postfix rewrote to From: w...@example.com w...@example.com Postfix rewriting controls are described here: http://www.postfix.org/ADDRESS_REWRITING_README.html#william Postfix doesn't normally rewrite headers in remote mail, but rewriting can still happen, such as if you have a content_filter. It may help to set in main.cf remote_header_rewrite_domain = domain.invalid to use @domain.invalid instead of your own domain in headers. http://www.postfix.org/postconf.5.html#remote_header_rewrite_domain -- Noel Jones That is exactly what is going on! Thanks everyone! Is such rewriting desirable in the general case? Or only when there is a specific need? the purist view is that you should not rewrite the message, including headers. This is the job of the client mail agent. trying to rewrite/fix will generally cause problems, because it is hard to guess what the user wanted to write. and if there's a problem, the general principle applies: fix problems at the source. on the other hand, if you know what you're doing, it's ok to fix things. but think twice before you think it's all right. and think 7 times before fixing inbound mail.
postfix using the name of the user who's sending the emaill
hi. in testing mail/postfix, i'm finding that the mail that i get on the destination/target email is sent from the user who's sent the email. is there an attribute that i can set within the postfix main.cf file to force that name to be foo... I've been looking but I can't find it... so i must have missed it! thanks
Re: SMTP AUTH not subjected to unnecessary check?
Voytek Eymont a écrit : I have Postfix with SMTP AUTH with self issued certificate, it all works well (as long as I don't touch it..) I have now allowed some users to use SMTP AUTH, but, some of their mail then gets evaluated as 'spam' by amavisd/spamassasin scores, amongst these, 'dynamic ip' type scores am I correctly exempting SMTP AUTH users from unnecessary anti-spam evals such as 'dynamic ip' 'direct access to smpt host' type of evals ? or is this something I need to in amavisd/spamassasin ? in other words, is my postfix setup correct ? and, optimal ? there is no evidence in your config that auth'ed mail gets a different ticket than other mail. the recommended way is to enable submission (port 587) and configure clients to use this port. This will be more and more common, and if you get here in a few years, this will be the only recommendation, because there is no point to complicate things when you can do it simply... now, you can still use check_* and return a FILTER statement. in any case, either skip amavisd-new (with content_filter or FILTER) or configure amavisd-new to listen to multiple ports, one of which doesn't do spam filtering. Google or other will bring more details. [snip]
Re: postfix using the name of the user who's sending the emaill
bruce a écrit : hi. in testing mail/postfix, i'm finding that the mail that i get on the destination/target email is sent from the user who's sent the email. is there an attribute that i can set within the postfix main.cf file to force that name to be foo... I've been looking but I can't find it... so i must have missed it! postfix is an MTA: a Mail Transport Agent. It takes client mail and pass it to destination. the place to write messages is in the Mail User Agent (MUA). of course, postfix has features to rewrite things. for example /^From: .*/ REPLACE From: f...@example.com will rewrite the From header, but I doubt this is what you want! (no, there is no lookup the header in mysql and replace with the value found there..). What problem are you trying to solve?
Re: Postfix Book
On 4-Mar-2010, at 11:47, Brian Evans - Postfix List wrote: On 3/4/2010 1:42 PM, Leonard Jacobs wrote: What happened to the Ralf and Patrick Book of Postfix book that seems to be out of print? Is there another edition scheduled or was the market just not large enough to keep the book in print? Is there another Postfix book recommended by the group? From the recent archives: http://archives.neohapsis.com/archives/postfix/2010-01/0891.html Maybe they should consider going with an eBook instead of dead-tree edition? I'd recommend contact Tonya Engst to...@tidbits.com (TidBITS, Take Control) who would at least have pointers on doing this right if she wasn't willing to do it for you under the TCO banner. www.takecontrolbooks.com/ I mean, this seems like a natural fit to be an ebook to me. -- I am enclosing two tickets to the first night of my new play; bring a friend if you have one. - GB Shaw to Churchill Cannot possibly attend first night, will attend second... if there is one. - Winston Churchill, in response.
Re: Postfix doesn't fall back on other IP addresses
Erik Logtenberg: If your system has no useful IPv6 connectivity, disable IPv6 in Postfix. http://www.postfix.org/inet_protocols The issue is that other people with broken IPv6 connectivity have trouble delivering mail to me, because my mailservers have many different IP addresses, both IPv4 and IPv6. Due to the default of a maximum of 5 IP addresses being tried before giving up, combined with the fact that IPv6 apparently has precedence over IPv4, no one with broken IPv6 can deliver mail to me when I have = 5 IPv6 addresses configured. Thank you for your tip nevertheless, if everyone would follow it, this problem wouldn't exist. Sites with broken IPv6 connectivity should not enable IPv6 on their systems. Wietse
Re: SMTP AUTH not subjected to unnecessary check?
On Fri, March 5, 2010 11:29 am, mouss wrote: Voytek Eymont a écrit : there is no evidence in your config that auth'ed mail gets a different ticket than other mail. the recommended way is to enable submission (port 587) and configure clients to use this port. This will be more and more common, and if you get here in a few years, this will be the only recommendation, because there is no point to complicate things when you can do it simply... Mouss, but I enabled 'submission' and use port 587 for SMTP AUTH, and, am I missing something? from master.cf .. submission inet n - n - - smtpd -o smtpd_tls_security_levels=encrypt -o smtpd_sasl_auth_enable=yes .. -- Voytek
Postfix Configuration to Allow Other Network Systems to relay through It
Hi. System A has postfix, and can relay successfully email through Gmail. System A is 192.168.1.56 System B is 192.168.1.59 System B has Postfix, and has the line relayhost [192.196.1.56]:25 I'd like to be able to have System B, relay it's mail through the configured Postfix on System A. When I simply try on System B, to send an email, I get a Connection Refused: err in the log file of System B. The docs imply that the Postfix on System A should be open to connections from other systems in the same 192.168.1.x subnet. There is a mynetworks line that's set to its default. Is there something else I missed on this. Thanks
Re: Anatomy of this simple spam.
Thanks everyone for illuminating the true problem for me! Josh
Re: Postfix Configuration to Allow Other Network Systems to relay through It
On Thu, Mar 04, 2010 at 05:44:21PM -0800, bruce wrote: System A has postfix, and can relay successfully email through Gmail. System A is 192.168.1.56 System B is 192.168.1.59 System B has Postfix, and has the line relayhost [192.196.1.56]:25 1. Seems strange that you would need two MTAs at this site; it is obvious that you don't have much volume if you're relaying through gmail. 2. man 5 postconf and pay attention to syntax. There is no = in what you're showing us here. I'd like to be able to have System B, relay it's mail through the configured Postfix on System A. When I simply try on System B, to send an email, I get a Connection Refused: err in the log file of System B. We can't help you unless you SHOW US these logs. The docs imply that the Postfix on System A should be open to connections from other systems in the same 192.168.1.x subnet. There is a mynetworks line that's set to its default. Oxymoron there: if there is a mynetworks line in main.cf, mynetworks isn't at its default. Is there something else I missed on this. The list welcome message and DEBUG_README.html#mail which tell you how to ask questions here which can be answered. Since B is the one with the problem, we'd want to see B's logs and postconf -n. But it wouldn't hurt to also see what A has in its postconf output: my WAG here would be that inet_interfaces is set. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Postfix Configuration to Allow Other Network Systems to relay through It
hey rob0.. thanks. my bad. forgot to post that i had solved this.. the inet_interfaces was set to localhost... thanks On Thu, Mar 4, 2010 at 6:56 PM, /dev/rob0 r...@gmx.co.uk wrote: On Thu, Mar 04, 2010 at 05:44:21PM -0800, bruce wrote: System A has postfix, and can relay successfully email through Gmail. System A is 192.168.1.56 System B is 192.168.1.59 System B has Postfix, and has the line relayhost [192.196.1.56]:25 1. Seems strange that you would need two MTAs at this site; it is obvious that you don't have much volume if you're relaying through gmail. 2. man 5 postconf and pay attention to syntax. There is no = in what you're showing us here. I'd like to be able to have System B, relay it's mail through the configured Postfix on System A. When I simply try on System B, to send an email, I get a Connection Refused: err in the log file of System B. We can't help you unless you SHOW US these logs. The docs imply that the Postfix on System A should be open to connections from other systems in the same 192.168.1.x subnet. There is a mynetworks line that's set to its default. Oxymoron there: if there is a mynetworks line in main.cf, mynetworks isn't at its default. Is there something else I missed on this. The list welcome message and DEBUG_README.html#mail which tell you how to ask questions here which can be answered. Since B is the one with the problem, we'd want to see B's logs and postconf -n. But it wouldn't hurt to also see what A has in its postconf output: my WAG here would be that inet_interfaces is set. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
