Re: Multiple From: in a mail header?
On Thursday 14 January 2010 19:14:48 Victor Duchovni wrote: It may be prudent to also treat: From: authorA From: authorB as synonymous with: From: authorA, authorB the implied meaning is that the people with those email addresses, co-authored the email. But have you seriously seen a mail client, which would allow sending such mail? I would think, this is an extreme rarity, but is it? signature.asc Description: This is a digitally signed message part.
Re: a little bit of help with aliases
Hi, Thanks for the help. Ok here is a little more detail... Postconf -n output address_verify_map = btree:/var/lib/postfix/address_verify alias_database = hash:/etc/aliases bounce_queue_lifetime = 2d broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix disable_vrfy_command = yes html_directory = no inet_interfaces = all invalid_hostname_reject_code = 450 mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/local/man maps_rbl_reject_code = 450 maximal_queue_lifetime = 2d mydestination = localhost.$mydomain, localhost mydomain = domain.tld myhostname = mail.domain.tld mynetworks = 127.0.0.0/8 172.16.1.0/16 newaliases_path = /usr/bin/newaliases non_fqdn_reject_code = 450 queue_directory = /var/spool/postfix readme_directory = no sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_helo_timeout = 120s smtp_mail_timeout = 120s smtp_rcpt_timeout = 120s smtp_starttls_timeout = 120s smtp_tls_CAfile = /etc/pki/tls/cert.pem smtp_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtp_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache smtpd_client_connection_count_limit = 5 permit_multi_recipient_bounce,h_pipelining, smtpd_helo_required = yes permit_unauth_destinationrmit_mynetworks smtpd_sasl_auth_enable = yes smtpd_sasl_exceptions_networks = $mynetworks smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_starttls_timeout = 120s smtpd_tls_CAfile = /etc/pki/tls/cert.pem smtpd_tls_ask_ccert = yes smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_dh1024_param_file = $config_directory/dh_1024.pem smtpd_tls_dh512_param_file = $config_directory/dh_512.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache tls_random_source = dev:/dev/urandom virtual_alias_maps = proxy:mysql:$config_directory/mysql/ mysql_virtual_alias_maps.cf virtual_gid_maps = static:12 virtual_mailbox_base = /ml/vmail virtual_mailbox_domains = proxy:mysql:$config_directory/mysql/ mysql_virtual_domains_maps.cf virtual_mailbox_maps = proxy:mysql:$config_directory/mysql/ mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 5000 virtual_transport = dovecot virtual_uid_maps = static:5000 so i am running a virtual setup using mysql for maps. when i try to send an email to root it gets sent to r...@mail.domain.tld, this email address doesnt exist, it is a local root account, so i have setup an alias in /etc/aliases which is root: external_acco...@domain.tld but this doesnt seem to be working. the mails just sit in the mail queue not being delivered to the local account. I hope this is enough information for people to help me. Hope someone can show me the error of my ways :) Thankyou in advance. Kind Regards Tony On Thu, Jan 14, 2010 at 11:26 PM, mouss mo...@ml.netoyen.net wrote: toneeeda...@googlemail.com a écrit : Hi, I wonder if anyone can help with what will probably be a very simple problem. I have setup postfix and am now just trying to setup my system so that all emails to root get redirected to an external address, this is done in teh aliases file ine /etc/ i have then ran newalises and all seems to be fine. If i then send an email to root it gets sent to r...@server1.domain.tld rather than r...@domain.tld. So it just sits in the queue, not knowing where to be delivered. The way you state it, it's not possible... - when you send mail to joe, it gets sent to j...@$myorigin. you can set: myorigin = $mydomain this way, root become r...@domain.tld (without the host part). more on this in the ADDRESS REWRITE README (if you don't know where this is, google will bring you there). if this doesn't solve your problem, please be more precise: - explain exactly what you want and what happens (try to be as precise as you can. don't forget that what may be natural for you is not natural for others...) - show the output of 'postconf -n'. more advice is found in the DEBUG README. can anyone point me in the direction of the bit of config that has to be changed please? Hope someone can help. Kind Regards Tony
Re: Multiple From: in a mail header?
On Friday January 15 2010 09:11:27 Kārlis Repsons wrote: But have you seriously seen a mail client, which would allow sending such mail? I would think, this is an extreme rarity, but is it? It is very rare alright. Multiple author addresses in a single From header field are legitimate, but some mail processing software breaks on them. Multiple From header fields are prohibited by rfc, but that does not stop malicious or broken senders from doing it if they feel like it. If one or the other turns out to be profitable for malware, it will be used, no doubt about it, so better be ready. Btw, of the header fields that may occur only once, it is currently more usual to see multiple Message-ID, or Subject, or To or Cc, or MIME-Version, or Content-Type. Very rare are duplicate Reply-To or Date. The least common is to see multiple From. Mark
Re: Multiple From: in a mail header?
On Friday 15 January 2010 09:29:37 Mark Martinec wrote: On Friday January 15 2010 09:11:27 Kārlis Repsons wrote: But have you seriously seen a mail client, which would allow sending such mail? I would think, this is an extreme rarity, but is it? It is very rare alright. Multiple author addresses in a single From header field are legitimate, but some mail processing software breaks on them. Multiple From header fields are prohibited by rfc, but that does not stop malicious or broken senders from doing it if they feel like it. If one or the other turns out to be profitable for malware, it will be used, no doubt about it, so better be ready. Btw, of the header fields that may occur only once, it is currently more usual to see multiple Message-ID, or Subject, or To or Cc, or MIME-Version, or Content-Type. Very rare are duplicate Reply-To or Date. The least common is to see multiple From. Mark Thanks! signature.asc Description: This is a digitally signed message part.
Re: a little bit of help with aliases
2010/1/15 toneeeda...@googlemail.com: Postconf -n output mydestination = localhost.$mydomain, localhost mydomain = domain.tld myhostname = mail.domain.tld mynetworks = 127.0.0.0/8 172.16.1.0/16 virtual_alias_maps = proxy:mysql:$config_directory/mysql/mysql_virtual_alias_maps.cf virtual_gid_maps = static:12 virtual_mailbox_base = /ml/vmail virtual_mailbox_domains = proxy:mysql:$config_directory/mysql/mysql_virtual_domains_maps.cf virtual_mailbox_maps = proxy:mysql:$config_directory/mysql/mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 5000 virtual_transport = dovecot virtual_uid_maps = static:5000 so i am running a virtual setup using mysql for maps. when i try to send an email to root it gets sent to r...@mail.domain.tld, this email address doesnt exist, it is a local root account, so i have setup an alias in /etc/aliases which is root: external_acco...@domain.tld but this doesnt seem to be working. the mails just sit in the mail queue not being delivered to the local account. I hope this is enough information for people to help me. I'm not 100% confident in my reading of your config, but this is what I think is happening: 1. Mail is submitted for root 2. This isn't a qualified email address, so Postfix appends @$myorigin (see http://www.postfix.org/postconf.5.html#append_at_myorigin) 3. $myorigin = $myhostname by default, so the recipient address is now r...@mail.domain.tld 4. /etc/aliases is only good for local deliveries, not virtual aliased addresses or virtual mailbox addresses. Local addresses are anything at $mydestination. 5. It should be evident that r...@mail.domain.tld isn't considered a local address now. Postfix now has to figure out what Address Class it belongs in, and handle it accordingly. All about address classes: http://www.postfix.org/ADDRESS_CLASS_README.html Now, I don't know what your mysql says about mail.domain.tld as a domain, so I don't know if it'd be treated as a virtual-alias or virtual-mailbox domain - I'm not really sure why it's stuck in the queue. If you want to pass this mail off to an external address, I think you can: 1. Add $myhostname to $mydestination, I believe this is the default configuration (ie. your changes to main.cf caused this breakage). /etc/aliases will then be effective yoshino:~# postconf mydestination # the effective value mydestination = $myhostname, localhost.$mydomain, localhost yoshino:~# postconf -d mydestination# matches the default value mydestination = $myhostname, localhost.$mydomain, localhost 2. Or I think you could add an entry to virtual_alias_maps for r...@mail.domain.tld - external_acco...@domain.tld. I'm not sure if you'd have to specify mail.domain.tld as a virtual_alias_domain first.
Postfix, mailman and procmail integration
Good morning, I am new to this list and I am not even sure if this is the place to start, but here goes. I have an Ubuntu 8.0.4 LTS server with postfix 2.5.1-2ubuntu1.2, mailman2.1.9-9ubuntu1 and procmail3.22-16ubuntu3. I have followed the instructions in the Ubuntu community pages regarding configuring postfix, mailman and procmail to work together and I can't seem to get mailman to pay attention to the procmail directives in /etc/procmailrcs/. Is there a trick to this? Anyone else have such a setup working? Thanks! Marc Taylor
Re: Postfix, mailman and procmail integration
On Fri, 15 Jan 2010, Taylor, Marc wrote: I am new to this list and I am not even sure if this is the place to start, but here goes. Probably not the right place. I have an Ubuntu 8.0.4 LTS server with postfix 2.5.1-2ubuntu1.2, mailman2.1.9-9ubuntu1 and procmail3.22-16ubuntu3. I have followed the instructions in the Ubuntu community pages regarding configuring postfix, mailman and procmail to work together and I can't seem to get mailman to pay attention to the procmail directives in /etc/procmailrcs/. You should join the Mailman Users list and ask there. Go to the Mailman hope page (http://www.gnu.org/software/mailman/index.html) and follow the Discussion Lists link. -- Larry Stone lston...@stonejongleux.com
Re: Postfix, mailman and procmail integration
Taylor, Marc: Good morning, I am new to this list and I am not even sure if this is the place to start, but here goes. I have an Ubuntu 8.0.4 LTS server with postfix 2.5.1-2ubuntu1.2, mailman2.1.9-9ubuntu1 and procmail3.22-16ubuntu3. I have followed the instructions in the Ubuntu community pages regarding configuring postfix, mailman and procmail to work together and I can't seem to get mailman to pay attention to the procmail directives in /etc/procmailrcs/. Is there a trick to this? Anyone else have such a setup working? Hmm... Would you be so kind to turn on your telepathic sensors and guess where I may have made a mistake while I tried to follow instructions. Please see the mailing list welcome message for guidance (repeated below). Wietse TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html Thank you for using Postfix.
gssapi sasl authentication
hi list, i want to authenticated my user on Kerberos AD by sasl My install work with cyrus but not with postfix In mail.info i can see the fllowing error Jan 15 17:23:00 auth postfix/smtpd[17540]: warning: SASL authentication failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Configuration file does not specify default realm) Jan 15 17:23:00 auth postfix/smtpd[17540]: warning: linagora-55e33d.w2k3.test[172.16.62.5]: SASL GSSAPI authentication failed: generic failure my main.cf file smtpd_sasl_auth_enable = yes smtpd_sasl_type = cyrus smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_sasl_local_domain = w2k3.test the /etc/postfix/sasl/smtpd.conf log_level: 6 pwcheck_method: saslauthd mech_list: GSSAPI the /etc/default/saslauthd START=yes DESC=SASL Authentication Daemon NAME=saslauthd MECHANISMS=kerberos5 MECH_OPTIONS= THREADS=5 OPTIONS=-c -m /var/spool/postfix/var/run/saslauthd -r W2K3.TEST the /etc/krb5.keytab contain auth:/etc/postfix# ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal - 13HTTP/auth.w2k3.t...@w2k3.test 23imap/auth.w2k3.t...@w2k3.test 33smtp/auth.w2k3.t...@w2k3.test 43host/auth.w2k3.t...@w2k3.test The client is windows XP integrated in AD domaine. On the thunderbird client i have the following config Use secure authentication username and password username is toto I have tried with t...@w2k3.test thanks
Re: gssapi sasl authentication
On Fri, Jan 15, 2010 at 05:34:16PM +0100, Lanfeust troy wrote: Jan 15 17:23:00 auth postfix/smtpd[17540]: warning: SASL authentication failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Configuration file does not specify default realm) The default (Kerberos) realm is specified in /etc/krb5.conf -- 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: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users 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: gssapi sasl authentication
sorry i forgot this config file
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
[libdefaults]
default_realm = W2K3.TEST
default_keytab_name = FILE:/etc/krb5.keytab
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
W2K3.TEST = {
kdc = kdc:88
admin_server = kdc:749
default_domain = w2k3.test
}
[domain_realm]
.w2k3.test = W2K3.TEST
w2k3.test = W2K3.TEST
2010/1/15 Victor Duchovni victor.ducho...@morganstanley.com
On Fri, Jan 15, 2010 at 05:34:16PM +0100, Lanfeust troy wrote:
Jan 15 17:23:00 auth postfix/smtpd[17540]: warning: SASL authentication
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more
information (Configuration file does not specify default realm)
The default (Kerberos) realm is specified in /etc/krb5.conf
--
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:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users
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.
SOLVED Re: gssapi sasl authentication
I solved this error by turning off chroot in master.fr for smtp service.
And i do a copy of /etc/krb5.conf in /var/spool/postfix/etc and turn on
chroot and is still work fine
Thanks
2010/1/15 Lanfeust troy lanfeus...@gmail.com
sorry i forgot this config file
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
[libdefaults]
default_realm = W2K3.TEST
default_keytab_name = FILE:/etc/krb5.keytab
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
W2K3.TEST = {
kdc = kdc:88
admin_server = kdc:749
default_domain = w2k3.test
}
[domain_realm]
.w2k3.test = W2K3.TEST
w2k3.test = W2K3.TEST
2010/1/15 Victor Duchovni victor.ducho...@morganstanley.com
On Fri, Jan 15, 2010 at 05:34:16PM +0100, Lanfeust troy wrote:
Jan 15 17:23:00 auth postfix/smtpd[17540]: warning: SASL authentication
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more
information (Configuration file does not specify default realm)
The default (Kerberos) realm is specified in /etc/krb5.conf
--
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:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users
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.
LDAP BCC Rules
Hi, we're trying to setup our Postfix relays to BCC emails to/from specific users (members of an LDAP group - A/D actually) to a mailbox that logs their correspondence. I wasnt able to find any mention of this in the online documentation anywhere - does anyone know of a way to implement something like this? We have this setup currently so that the backend M$ Exchange does this for us, but would love to offload this functionality from there. Thanks
Re: LDAP BCC Rules
Joe Postfix: Hi, we're trying to setup our Postfix relays to BCC emails to/from specific users (members of an LDAP group - A/D actually) to a mailbox that logs their correspondence. I wasnt able to find any mention of this in the online documentation anywhere - does anyone know of a way to implement something like this? Adding recipients: http://www.postfix.org/postconf.5.html#always_bcc http://www.postfix.org/postconf.5.html#sender_bcc_maps http://www.postfix.org/postconf.5.html#recipient_bcc_maps http://www.postfix.org/postconf.5.html#virtual_alias_maps LDAP lookups: http://www.postfix.org/ldap_table.html Wietse We have this setup currently so that the backend M$ Exchange does this for us, but would love to offload this functionality from there. Thanks
Re: LDAP BCC Rules
On Fri, Jan 15, 2010 at 03:44:11PM -0500, Joe Postfix wrote: Hi, we're trying to setup our Postfix relays to BCC emails to/from specific users (members of an LDAP group - A/D actually) to a mailbox that logs their correspondence. I wasnt able to find any mention of this in the online documentation anywhere - does anyone know of a way to implement something like this? We have this setup currently so that the backend M$ Exchange does this for us, but would love to offload this functionality from there. If you can formulate an LDAP query that returns an entry with a suitable non-empty attribute (ideally the Bcc destination address) for users whose mail needs the Bcc, and returns a different entry or no entry for users who don't, then you can use query to build an LDAP table for Postfix. -- 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: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users 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: LDAP BCC Rules
Thanks! BTW this link for LDAP lookups works better for me: http://www.postfix.org/LDAP_README.html#config On Fri, Jan 15, 2010 at 3:53 PM, Wietse Venema wie...@porcupine.org wrote: Joe Postfix: Hi, we're trying to setup our Postfix relays to BCC emails to/from specific users (members of an LDAP group - A/D actually) to a mailbox that logs their correspondence. I wasnt able to find any mention of this in the online documentation anywhere - does anyone know of a way to implement something like this? Adding recipients: http://www.postfix.org/postconf.5.html#always_bcc http://www.postfix.org/postconf.5.html#sender_bcc_maps http://www.postfix.org/postconf.5.html#recipient_bcc_maps http://www.postfix.org/postconf.5.html#virtual_alias_maps LDAP lookups: http://www.postfix.org/ldap_table.html Wietse We have this setup currently so that the backend M$ Exchange does this for us, but would love to offload this functionality from there. Thanks
Re: LDAP BCC Rules
On Fri, 15 Jan 2010 15:53:10 -0500 (EST) Wietse Venema wie...@porcupine.org replied: LDAP lookups: http://www.postfix.org/ldap_table.html Shouldn't that be: http://www.postfix.com/LDAP_README.html -- Jerry postfix.u...@yahoo.com TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html An ounce of mother is worth a ton of priest. Spanish proverb
tigertech mirror broken
http://www.postfix.org/download.html US, CA, Bay area http://www.tigertech.net/mirrors/postfix-release/index.html goes to a landing page, not a postfix download mirror
Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.
Solved ... On January 13, 2010 1:06:10 PM -0500 Wietse Venema wie...@porcupine.org wrote: Well, if you can provide unmodified evidence, then people can look into this. Yeah unfortunately as I said, I couldn't do that. And anyway I wasn't looking for folks to fix my problem so much as have the discussion so I could get help letting me know where to look. In the first place I got sidetracked because the only discussion I found on multiple PTR records (and it was a recent discussion) was that postfix did not handle them and had no intentions of doing so. I learned that was wrong and hopefully the next person to search for that problem will find these threads and see postfix does handle them in the only way that makes sense. I won't bore you with all the details, and they are numerous, except to say that I have learned that I have to trust my skills in debugging. I let clues go right by because I just assumed I must not be running the tools correctly (tcpdump, sotruss, etc). But I have vast experience and really I should have had confidence that I do know what I'm doing. It turns out that the problem was a firewall rule. My MX host is in a DMZ (natch) but my resolvers are inside. There is a udp/53 hole in the firewall. But because this was such a large PTR record, the nameserver indicated truncation and the resolver had to go to TCP. Now most of those records would be thrown away so it doesn't matter, but the resolver doesn't know that. Normally I configure (patch) named to use a very large truncation threshold; I think the default is very low, 500 bytes or so and in this case I would normally set it to 8900-ish since we are jumbo frames everywhere. Then this problem wouldn't have come up, at least not at this time. But for reasons I don't know anymore, this named is just a vanilla named. I do have some suggestions for postfix; things that would have helped me solve this much sooner and maybe would be useful in general. 1) It makes absolute sense that postfix not start logging a connection until a name lookup has been done. But if that name lookup takes a very long time, along with the connect postfix should log how long ago the actual connect was. Syslog will of course only log the current time, ie the time the log message is received, however the actual connect may have been eons ago and the timestamp is now wrong. Not just for this specific case, but in general it helps if the connect time is recorded for purposes of log correlation. I would say that if the time since connect() and the return of getnameinfo() is more than 1s, the delta should be logged. postfix already keeps timing info so I would hope that this additional info isn't an extensive change. 2) There is something going on where postfix wasn't logging connects from my test host, which sent FIN instead of the actual problem host which was sending RST. My guess would be that postfix is blocking on getnameinfo() so I don't see how the status of the client connection even comes into play, but it is curious. For (2) you can probably reproduce it by creating a host with many PTR records and blocking tcp/53 from the test postfix server. I'm sorry that I can't spend any more time on this to provide testing help (if you even want to pursue it). I'm swamped right now with active directory problems and this problem was just an emergency that came up. -frank
