RE: Perl milters?
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Kouhei Sutou Sent: Wednesday, March 14, 2012 5:28 PM To: postfix-users@postfix.org Subject: Re: Perl milters? Another consideration was that I do not know how to test milters without running full MTA. milter manager (*) has a test program to do it. The test program is milter-test-server: http://milter-manager.sourceforge.net/reference/milter-test- server.html (*) http://milter-manager.sourceforge.net/ OpenDKIM (http://www.opendkim.org) also includes a Lua-driven milter exercise program called miltertest. We use it to exercise all of our run-time filter unit tests before every release. Documentation: http://www.opendkim.org/miltertest.8.html ...with numerous examples in the source tarball. -MSK
RE: Domain keys for postfix mail server
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of KingT Sent: Monday, February 27, 2012 7:29 PM To: 'postfix users' Cc: 'Noel Jones' Subject: RE: Domain keys for postfix mail server Thanks your reply Noel Jones , I am finding a some document to config opendkim work with postfix, have you document or tutorial ? A simple Google search reveals: http://www.elandsys.com/resources/mail/dkim/opendkim.html http://agiletesting.blogspot.com/2010/03/dkim-setup-with-postfix-and-opendkim.html http://stevejenkins.com/blog/2010/09/how-to-get-dkim-domainkeys-identified-mail-working-on-centos-5-5-and-postfix-using-opendkim/
RE: Strange SASL Authentication Issue
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Robert Krig Sent: Thursday, January 12, 2012 3:03 AM To: Postfix users Subject: Re: Strange SASL Authentication Issue I think I might have identified the problem. Apparently in some situations SASLauthd can produce memory leaks. This is what I've gathered from other people's posts. Now I'm not certain if this is what was causing my particular issue (too soon to tell), but it's worth checking out. You might test this by restarting saslauthd once the problem appears. If that causes the symptom to stop, you have stronger evidence that the problem is there. -MSK
Including state information in Received fields
Hi, I'm co-authoring a draft that would add supplementary information to Received header fields indicating when a message enters some kind of administrative hold. This would be useful to people looking through trace data to figure out why a message sat on a machine for some time, if the reason is something other than a hop that took a long time to complete for connectivity reasons. The draft specification is here: https://datatracker.ietf.org/doc/draft-kucherawy-received-state/ Would postfix be willing to implement something like this? At a minimum, it might be useful to use this to indicate that a milter application requested that a message be quarantined until an operator released it. Thanks, -MSK
RE: Including state information in Received fields
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Peter Blair Sent: Wednesday, January 11, 2012 10:21 PM To: Postfix users Subject: Re: Including state information in Received fields I've found that people don't always want to have this made known. When tracking down why did mail take X hours to reach my friend's inbox issues, it would be quite the embarrassment to have the tracer headers show that my work was being rate limited by ISP X. The MTA being subjected to rate limiting would have to know it's being rate-limited in order to be able to log that in a state clause. If all it's getting is temp-fails, it doesn't know it's in such a state. The intent here is to enable an MTA to log that a message is in a particular state when the local MTA (or an adjacent local component like an MLM) is the one making that decision, not when some downstream MTA (i.e. the next hop) is doing so.
RE: Postfix and MIMEdefang; per-recipient treatment of messages in a milter environment
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Tuesday, November 22, 2011 2:23 PM To: Postfix users Subject: Re: Postfix and MIMEdefang; per-recipient treatment of messages in a milter environment This is not reliable. If one recipient mail transaction fails (no disk space or whatever) then you must report a tempfail error to the remote SMTP client. Later, the SMTP client will send the whole message again, WITH THE THE SAME RECIPIENTS AS BEFORE. In other words, if one recipient transaction fails, other recipients will receive an extra copy of the message. Or you return DSNs for the ones that fail after 250ing the incoming transaction. But that has its own issues, e.g., backscatter. It's a shame http://tools.ietf.org/id/draft-hall-prdr-00.txt or something like it never went anywhere.
RE: Postfix and MIMEdefang; per-recipient treatment of messages in a milter environment
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Tuesday, November 22, 2011 4:50 PM To: Postfix users Subject: Re: Postfix and MIMEdefang; per-recipient treatment of messages in a milter environment Or you return DSNs for the ones that fail after 250ing the incoming transaction. But that has its own issues, e.g., backscatter. Return a DSN for a tempfailed recipient? Sure, doesn't postfix return a DSN after some period if delivery hasn't been successful?
RE: reject_non_fqdn_helo_hostname usefulness, safety
Just heard back from them: Murray, FYI, I was just notified by the correct person within eBay that this is being fixed now. Thank you again for forwarding it along. -MSK From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Murray S. Kucherawy Sent: Friday, November 11, 2011 11:47 PM To: Steve Fatula; simon.brere...@buongiorno.com; postfix users Subject: RE: reject_non_fqdn_helo_hostname usefulness, safety I've forwarded this to some standards and practices compliance people inside eBay/PayPal. I bet they'll be quite interested. I know that they were planning to do some work on their DK/DKIM infrastructure at some point. Maybe this was a side-effect. Will advise when they reply. -MSK From: owner-postfix-us...@postfix.orgmailto:owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Steve Fatula Sent: Thursday, November 10, 2011 9:04 PM To: simon.brere...@buongiorno.commailto:simon.brere...@buongiorno.com; postfix users Subject: Re: reject_non_fqdn_helo_hostname usefulness, safety From: Simon Brereton simon.brere...@buongiorno.commailto:simon.brere...@buongiorno.com To: postfix users postfix-users@postfix.orgmailto:postfix-users@postfix.org Sent: Thursday, November 10, 2011 9:26 PM Subject: Re: reject_non_fqdn_helo_hostname usefulness, safety Write them a note with the RFC I say. Standards are no good if you let yours slip because it's Ebay. or Google. or InsetBrandnamehere. I did exactly that. Have not heard back yet, if I ever will. I included some sample log messages so they could see some of the servers with the bad HELO name, not all of them have it, and of course the relevant RFC section. They had some Paypal/Ebay troubles today as well (some payments could not be made via Ebay checkout), and, I see they are making announced website changes starting tonight as well. Perhaps it was a lot of work and they just screwed up. Hopefully, some one who knows something will read the email and actually do something! I did whitelist them in the meantime to avoid the check.
RE: Milter issue with Postfix 2.8.7 and pymilter (compiled against Sendmail 8.14.4)
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Sunday, November 13, 2011 2:27 PM To: Postfix users Subject: Re: Milter issue with Postfix 2.8.7 and pymilter (compiled against Sendmail 8.14.4) Otherwise, you'll have to figure out with pyMilter source code what part of the Postfix handshake request it is objecting to. It could also be that the pyMilter callback for the negotiation step that your application provides is not handling negotiation cleanly.
RE: reject_non_fqdn_helo_hostname usefulness, safety
I've forwarded this to some standards and practices compliance people inside eBay/PayPal. I bet they'll be quite interested. I know that they were planning to do some work on their DK/DKIM infrastructure at some point. Maybe this was a side-effect. Will advise when they reply. -MSK From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Steve Fatula Sent: Thursday, November 10, 2011 9:04 PM To: simon.brere...@buongiorno.com; postfix users Subject: Re: reject_non_fqdn_helo_hostname usefulness, safety From: Simon Brereton simon.brere...@buongiorno.commailto:simon.brere...@buongiorno.com To: postfix users postfix-users@postfix.orgmailto:postfix-users@postfix.org Sent: Thursday, November 10, 2011 9:26 PM Subject: Re: reject_non_fqdn_helo_hostname usefulness, safety Write them a note with the RFC I say. Standards are no good if you let yours slip because it's Ebay. or Google. or InsetBrandnamehere. I did exactly that. Have not heard back yet, if I ever will. I included some sample log messages so they could see some of the servers with the bad HELO name, not all of them have it, and of course the relevant RFC section. They had some Paypal/Ebay troubles today as well (some payments could not be made via Ebay checkout), and, I see they are making announced website changes starting tonight as well. Perhaps it was a lot of work and they just screwed up. Hopefully, some one who knows something will read the email and actually do something! I did whitelist them in the meantime to avoid the check.
RE: dkim-milter verify, but don't sign.
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Josef Karliak Sent: Monday, November 07, 2011 3:50 AM To: Robert Schetterer Cc: postfix-users@postfix.org Subject: Re: dkim-milter verify, but don't sign. Hi, thanks for tips, I used -i ilistfile containing list of internal (signing) hosts. It is signing now, but signature fails on the verifier : Nov 7 12:40:54 celer dkim-filter[4888]: 5CCC8C750A SSL error:04077068:rsa routines:RSA_verify:bad signature Nov 7 12:40:54 celer dkim-filter[4888]: 5CCC8C750A: bad signature data Both dkim-filter (which is now obsolete, and 2.7.2 wasn't the most recent release anyway) and opendkim have tools to debug these problems, especially if you are both the signer and the verifier as you are in this case. But this isn't a postfix problem. I suggest upgrading to opendkim and then posting your question on the opendkim-users list. -MSK
RE: executive parser (was: Re: spf configuration woes)
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of David Southwell Sent: Saturday, November 05, 2011 9:41 AM To: postfix-users@postfix.org Cc: /dev/rob0 Subject: Re: executive parser (was: Re: spf configuration woes) Just to add weight to my last posting - the use of a as a critical symbol is really quite idiotic. What cannot be seen should never be that significant! The current RFC defining email message format is RFC5322, and it uses leading whitespace as line continuation in header fields. Its antecedents, going back as far as RFC733 (1977) and perhaps further, do the same thing. Thus, your assertion appears to be in conflict with quite a bit of operational history and experience.
RE: Content filter after DKIM proxy
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Simon Brereton Sent: Wednesday, October 19, 2011 2:36 PM To: postfix users Subject: Re: Content filter after DKIM proxy And I'd like to implement dnssec as well). OpenDKIM supports DNSSEC (via libunbound). You're set! :-)
RE: Authenticated sender and milter
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Kris Deugau
Sent: Wednesday, September 21, 2011 8:06 AM
To: Postfix users
Subject: Re: Authenticated sender and milter
man mimedefang-filter has the complete list of globals, and fairly clear
notes on which sendmail macros are available at which stages of
filtering. AFAICT Postfix automatically provides most of them; it's
only if you're using sendmail that you have to specifically tell it to
provide some of these macros to the milter.
I'm pretty sure the default list for sendmail is the same as the default list
for postfix. To wit:
Sendmail:
O Milter.macros.envfrom=i, {auth_type}, {auth_authen}, {auth_ssf},
{auth_author}, {mail_mailer}, {mail_host}, {mail_addr}
Postfix:
milter_mail_macros = i {auth_type} {auth_authen} {auth_author} {mail_addr}
{mail_host} {mail_mailer}
RE: DKIM signing problem
Wietse's advice is the first thing I would try: Eliminate anything that modifies your message after signing. The most common signature failure in our analysis apart from DNS setup problems has been a message that was malformed in the first place, so when it gets fixed someplace downstream, the signatures break. Interestingly, a malformed To: field was the biggest culprit. I suggest trying again with OpenDKIM (http://www.opendkim.org). The dkim-milter package has been unmaintained for a couple of years now. It lives on under the new name, with lots of bug fixes and new features since dkim-milter's final release. If it still fails, you can get some debugging help on the OpenDKIM support lists, including some tips for figuring out what's getting changed after signing and (possibly) where and why. -MSK
RE: What does Postfix stamp...
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix- us...@postfix.org] On Behalf Of Kris Deugau Sent: Friday, September 09, 2011 6:32 AM To: postfix-users@postfix.org Subject: Re: What does Postfix stamp... Not to mention, at least in my experience it's the IP that introduced the message to the Internet (ie, the sending client's IP, or webmail user's IP), not the IP that connected to your server. More often than not, that's what people actually want because it identifies who really sent the message, not who last handled it before you got it. But it's unreliable for all kinds of reasons: - it could be forged to indicate it came from a legit source when it didn't - there could be more than one of them, so which one do you believe? - it might be stripped in transit - it's non-standard If its value can't be trusted, you should just ignore it.
RE: What does Postfix stamp...
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Michael C. Robinson Sent: Thursday, September 08, 2011 4:31 PM To: postfix-users@postfix.org Subject: What does Postfix stamp... With amavis, I guess that postfix receives a message, throws it to amavis, and then amavis throws it back to postfix on another port. Why isn't postfix stamping the remote IP address before it hands the email off? X-Originating-IP: isn't standard, so I'm not surprised postfix isn't adding it by default. And I wouldn't trust it anyway; how do you know it contains a true value? However, Received: is, which very likely contains the information you want, and I'm fairly certain postfix does add that.
RE: SRS for Postfix
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Thursday, September 01, 2011 6:12 AM To: Hieronim Sokolski Cc: postfix-users@postfix.org Subject: Re: SRS for Postfix If you find a 100% Milter-based SRS solution then you are welcome to report to the mailing list. The ones that I found invoke socketmaps from sendmail.cf, instead of using the Milter SMFIR_CHGFROM (replace sender) command which is available since Postfix 2.6. At this point it would probably make sense to add Sendmail-style socketmap support to Postfix. Which ones had you found? I'd be interested to take a look at them. (I'm not a fan of SRS, but I'm interested in milter-related mechanics.)
RE: Request For Port 587
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jeroen Geilman Sent: Thursday, August 18, 2011 9:03 AM To: postfix-users@postfix.org Subject: Re: Request For Port 587 This is now a Draft standard, meaning you'd better follow it (HTML has never progressed beyond a draft standard in the 10+ years that v4.01 is in use) This requirement is updated from RFC 2476, where it was optional, but RFC 4409 is from April 2006 (a good 5 years ago), so let's assume people have read it by now. Even better, it's now being considered by the IETF for promotion to Full Standard. And there actually aren't very many of those (there are about 6300 RFCs, but fewer than 100 full standards).
RE: Outbound mail rate limits by user
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Saturday, August 13, 2011 6:36 PM To: Postfix users Subject: Re: Outbound mail rate limits by user No matter what MTA you use, it will need to know a) how many the sender has sent and b) what the limit for that sender is. Therefore, some per-sender configuration is unavoidable. I think a milter that tracks per-sender traffic outbound is the best idea. The MTA doesn't have to know anything other than how to talk to the milter, so the source and configuration stay clean; the milter can contain all the knowledge of local user databases (LDAP/SQL/whatever), per-user limits that might vary by class-of-service, etc. And a single milter can be referenced by multiple MTAs, so this could easily be a single site-wide facility. The only question you have to ask is how to identify a user reliably. Someone who knows you're rate-limiting outbound could easily spoof the From: or MAIL FROM to try to get around it; you'll need to handle attacks like that. I've implemented stuff like this before with milter, so I know it can be done. -MSK
RE: Order of milter execution
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Steve Fatula Sent: Tuesday, August 09, 2011 11:48 PM To: Postfix Users Subject: Order of milter execution Using Postfix 2.8.4, I have the following options to smtpd: -o content_filter=dspam:unix:/var/dspam/dspam.sock -o smtpd_milters=unix:/var/run/clamav/clamav- milter.sock,unix:/var/run/opendkim/opendkim.sock,unix:/usr/local/var/mi lter-greylist/milter-greylist.sock Reading the postfix doc, it says that Milter applications are applied in the order as specified. Yet, in the maillog I see milter-greylist listing messages before opendkim. I was wanting to use the results of opendkim in milter-greylist. Perhaps that is not really possible? My guess, from my limited milter understanding, is they are executed piecemeal and that order is perhaps not so predictable. In the sendmail implementation, milters operate in order specifically so that filters later in the chain see the effects of those that come before. For example, a header field added by the first one is visible to all the others. This is really the only practical option since doing them all in parallel might mean two filters request changes to the messages that conflict because their respective views show the original message, not the modified one. I can't imagine postfix would have done it any differently, partly because of the above design, and partly because that would mean the same combination of filters would have a different outcome if you change MTAs, and that's just not good. -MSK
RE: Postscreen, SPF and DKIM?
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Steve Fatula Sent: Tuesday, August 09, 2011 11:12 AM To: Postfix Users Subject: Postscreen, SPF and DKIM? However, it is good practice to reject mail that fails spf or dkim tests, since theoretically it is forged. And if it isn't then, the sender will be made aware that they have an error in their setup. It would be better to reject these before they ever get to the smtp server, would it not? Seems like this would be a function, if fast enough, that would fit the intended use of postscreen. Postfix architecture aside, I think this is bad advice, at least about DKIM. The premises are false.
RE: Postscreen, SPF and DKIM?
-Original Message- From: Steve Fatula [mailto:compconsult...@yahoo.com] Sent: Tuesday, August 09, 2011 1:15 PM To: Murray S. Kucherawy; Postfix Users Subject: Re: Postscreen, SPF and DKIM? Care to elaborate? Clearly, this is not possible to do in postscreen sort of making this moot, but, SPF spec says to reject messages that have status fail. DKIM says you MAY, and, several pieces of software such as dkim-milter allow you to do so. Also, ADSP records seem to have the capability to say please discard this message under various conditions, why shouldn't that be respected? Gmail (at least) already REJECTS mail based on dkim, at least for some domains like ebay.com I suppose to prevent phishing from reaching inbox or spam folders. I am not as familiar with DKIM as I am SPF. It would be helpful to know what specifically is wrong with the premise, and more importantly, why rejecting would be wrong. I realize there are some issues such as modified headers that can cause signature verification errors, however, the dkim-milter at least accounts for this by using the relaxed mode. I realize this is off-topic but it might be of interest to the Postfix community so I'll reply here until someone tells me to stop. A DKIM signature can fail to verify for perfectly legitimate reasons. The list of possible reasons is large, not the least of which is a signed message that traverses a mailing list that makes major header or body changes, or an MTA that rewrites important header fields like From:. If you treat such messages as suspicious, then you will begin to think DKIM has a huge false negative problem. That's why we wrote the DKIM specifications to be very clear about warning people not to treat a message with a broken signature any differently than one would treat an unsigned message. ADSP is dangerous. We've seen many cases in the wild that back up this claim. Three examples: - a certain open source MTA (not postfix) doesn't pass DSNs/MDNs it generates through its signing filters (if enabled), which means if you advertise an ADSP policy other than unknown, you're immediately violating your own policy - several sites that use ADSP then let their users post mail to lists, many of which invalidate signatures, so legitimate list postings get discarded or (worse) rejected on delivery - in this latter case, the rejection hits the MLM, which decides the recipient's mail is bouncing and unsubscribes the user even though its mail is otherwise just fine Gmail does NOT reject mail based on DKIM, unless Gmail has a prior non-protocol arrangement with a sender to do so, one that involves contracts signed by both parties, such as ebay.com or paypal.com. Gmail has said publicly they will never honour something like ADSP because it is a legal exposure. The dkim-milter (you should switch to opendkim, by the way; dkim-milter is unmaintained), use of relaxed header canonicalization is not a way around the signature invalidation problem overall. It does not account for the header changes that most commonly invalidate signatures. There is (currently) no solution for that other than to get lists to quit modifying messages and get clients to generate legal email so the MTAs don't have to fix it for them post-signing. To understand how to use all of these things properly, try to break the deeply-engrained mindset that we're trying to identify bad stuff to keep out. Rather, start thinking about how to identify the good stuff to let in. That's when DKIM is most useful. -MSK
RE: Large ISP which use Postfix
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Frank Bonnet Sent: Thursday, July 14, 2011 10:08 PM To: postfix-users@postfix.org Subject: Re: Large ISP which use Postfix Anyone knows what Google or Hotmail use ? I'm over 90% sure they each rolled their own.
RE: Error 550
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jack Sent: Thursday, June 23, 2011 11:10 AM To: postfix-users@postfix.org Subject: RE: Error 550 I searched the all knowing google but wasn't able to find what this 555 really means. Can someone please tell me what this means and if there is something I can do on my side or if it's only on the receivers side. Jun 13 12:51:48 pluto postfix/smtp[6897]: D83CF364024: to=mi...@receivingserver.com, relay=mail.receivingserver.com[197.9.228.14]:25, delay=4.1, delays=0.69/0/0.16/3.2, dsn=5.0.0, status=bounced (host mail.receivingserver.com[197.9.228.14] said: 555 (in reply to end of DATA command)) i guess you should write to the postmaster of the remoteserver to tell him that his config is idiotic becaue this way no (safe) automatic bounce-managment is possible So are we saying this is not a valid error code?? RFC5321 says it is. It means the MAIL FROM or one of the RCPT TO commands was invalid or used unimplemented features. (Why that's done in response to DATA and not at MAIL FROM or RCPT TO is puzzling, though.)
RE: signing multiple domains with dkim
OpenDKIM has ample documentation. Did you try working with that first?
http://www.opendkim.org/docs
-MSK
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of kshitij mali
Sent: Monday, June 20, 2011 1:04 AM
To: Patrick Ben Koetter
Cc: postfix-users@postfix.org
Subject: Re: signing multiple domains with dkim
Hello Patrick ,
Will u share some doc how to get opendkim work with postfix MTA.
Such has installation and administration , configuration , troubleshooting etc.
Regards,
Kshitij
On Mon, Jun 20, 2011 at 12:52 PM, Patrick Ben Koetter
p...@state-of-mind.demailto:p...@state-of-mind.de wrote:
Am 20.06.2011 07:50, schrieb Suresh Kumar Prajapati:
Hi,
Can anyone tell me how to sign mails for multiple domains .
My recommendation: Drop dkim-milter because IIRC it is unmaintained.
Get the followup opendkim http://opendkim.org instead.
If you follow dkim-filter read into KeyList:
# KeyList is a file containing tuples of key information. Requires
# KeyFile to be unset. Each line of the file should be of the format:
#sender glob:signing domain:signing key file
# Blank lines and lines beginning with # are ignored. Selector will be
# derived from the key's filename.
#KeyList/etc/dkim-keys.conf
p@rick
here is my dkim conf file
# To sign only, use -bs
# EXTRA_FLAGS=-bs
USER=dkim-milter
SOCKET=inet:8891@localhost
#PORT=inet:10034@localhost
SIGNING_DOMAIN=domain.comhttp://domain.com
SELECTOR_NAME=dktest
KEYFILE=/etc/mail/domainkeys/dkim_${SELECTOR_NAME}.pem
SIGNER=yes
VERIFIER=yes
CANON=simple
SIGALG=rsa-sha1
REJECTION=bad=r,dns=t,int=t,no=a,miss=r
EXTRA_ARGS=-h -l -D
MILTER_GROUP=mail
--
state of mind ()
Digitale Kommunikation
http://www.state-of-mind.de
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht MünchenPartnerschaftsregister PR 563
RE: security vulnerability : SMTP daemon supports EHLO
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Rich Wales Sent: Tuesday, May 03, 2011 9:18 AM To: postfix users Subject: Re: security vulnerability : SMTP daemon supports EHLO I can imagine that some hackers might use the SIZE info in an EHLO response as an invitation to try to crash a server by sending huge messages that are just under the advertised maximum length -- hence the idea of omitting this item from the EHLO response. I'd certainly be interested in hearing other thoughts about EHLO-related security concerns. It's hard to give a general answer, but specifically, every SMTP extension listed by EHLO has an RFC that defines it, and those each have a Security Considerations section. So if you want to be ultra-diligent, go read them all and then turn off the ones that scare you.
RE: bcc: header
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Reindl Harald Sent: Wednesday, March 23, 2011 1:00 PM To: postfix-users@postfix.org Subject: Re: bcc: header Am 23.03.2011 20:55, schrieb Jeroen van Aart: I tried the following in telnet session, but for some reason the email is only sent to the rcpt to: address. None of the Bcc'ed addresses receive a copy. Am I missing something obvious? rcpt to: n...@example.com 250 2.1.5 Ok data 354 End data with CRLF.CRLF bcc: somen...@example.net, anothern...@example.org testing BCC is a header so why you put it in the mail-body? He didn't. The header is what's before the blank line and the body is what's after the blank line. He has it right in terms of format, but is missing the important details of how SMTP works.
RE: bcc: header
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jeroen van Aart Sent: Wednesday, March 23, 2011 2:21 PM To: Postfix users Subject: Re: bcc: header The post service doesn't care what Cc: you write on your letters either, but only looks at the envelope. Yes, I assumed an MTA may do some extra processing based on the headers added after DATA. MTA history goes back to sendmail, which had three main modes for injecting a message: 1) sendmail user@host [message header and body here] [. or EOF] 2) sendmail -t [message header and body here] [. or EOF] 3) sendmail -bs (or connect via TCP to the SMTP port) 220 ... HELO ... 250 ... MAIL FROM: ... 250 ... RCPT TO: ... 250 ... DATA 354 ... [message header and body here] . 250 ... QUIT 221 ... [close connection] In mode (1) above, the recipient(s) are taken from the command line. In mode (2) above, the recipients are parsed out of the header of the message. In mode (3) above, the recipients are specified by RCPT TO:, which can appear multiple times. The only case where Bcc: actually has its value used is (2). For that matter, that's also the only place the values of To: and Cc: are actually used. I believe postfix presents all of these interfaces one way or another, so if your application is really keen to specify recipients in the header and not via SMTP or the command line, look for the postfix equivalent of (2). But since it seems like you're most of the way toward SMTP support, just add more RCPT TO lines and leave Bcc: since it will very likely be deleted without being used anyway. -MSK
RE: Non-smtp milter application and sasl macros
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Mehmet Tolga Avcioglu Sent: Wednesday, March 16, 2011 3:21 AM To: Postfix users Subject: Re: Non-smtp milter application and sasl macros Well, it seems obvious now that a well crafted milter application should check to see if macros are defined first before assuming they are there... Yes, and there are other good reasons for that. One is that different MTAs set different macros at different times. For example, with sendmail the value of the i macro is set with the MAIL FROM, but with postfix it's set later in the SMTP sequence, so an application can't assume it's available at MAIL FROM if the intent is to have it work with any milter-aware MTA.
RE: Problems with postfix while sending emails
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Ralf Hildebrandt Sent: Tuesday, March 15, 2011 9:55 AM To: postfix-users@postfix.org Subject: Re: Problems with postfix while sending emails * Rafael Azevedo raf...@gmail.com: Ralf, you're the g-e-n-i-o-u-s The problem is with DK-MILTER not DKIM. Doesn't DK-Milter do DKIM? No, it only does DomainKeys, which is historic. And dk-milter has bugs, and is no longer supported. Anybody running it should seriously consider turning it off.
RE: message id is a unique number?
For what it's worth, sendmail's implementation encodes the current time down to the second plus the pid of the handling process in its queue IDs. A collision then could only happen if the same pid got re-used twice in the same second. It doesn't include the inode or any random data. Details: http://www.ale.org/pipermail/ale/2001-May/022331.html Similar to the issue of log correlation, in the OpenDKIM stats project work we had to have an SQL key across the reporting host, queue ID and timestamp columns to account for the fact that postfix recycles queue IDs, sometimes relatively quickly. -MSK
RE: Message is modified after after-queue filter
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Victor Duchovni Sent: Tuesday, March 08, 2011 2:02 PM To: postfix-users@postfix.org Subject: Re: Message is modified after after-queue filter My current work-around is to correctly format my emails in my software before they are sent to postfix so that the messages are not modified at all. But that is not the best solution. Actually that *is* the best solution. Send 7-bit encoded mail with correct line endings. Furthermore, even if postfix could be coerced into not doing the rewrites you're describing, something else down the chain likely will, invalidating your signatures anyway. The best thing to do is try to minimize that from happening anywhere between you and the verifier. -MSK
RE: Spam Backscatter
A technology called BATV was proposed but never got widespread adoption (so far). There is at least one open source filter that implements it that you could try, though it is unmaintained. It has a few side effects, so read up on it before throwing the switch. From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Simon Sent: Tuesday, February 01, 2011 3:39 PM To: postfix users list Subject: Spam Backscatter We are using postfix with debian lenny... We are receiving what appears to be backscatter from spam that is using a valid address in the Return Path. I have included an example of the header info from one of the spam messages below. The From and To addresses just seem to be random and are not related to us in any way. Does anyone know to block this sort of backscatter? Original message headers: Return-Path: soa@*mailto:s...@newmedia.net.nz*[ourdomain.actual.domain]** Received: from 195-191-72-102.optolan.net.uahttp://195-191-72-102.optolan.net.ua (unknown [195.191.72.102]) by smtp-0.counselschambers.com.auhttp://smtp-0.counselschambers.com.au (Postfix) with ESMTP id 1D400396B7E for so...@tenthfloor.orgmailto:so...@tenthfloor.org; Wed, 2 Feb 2011 08:28:43 +1100 (EST) From: no-reply...@job.commailto:no-reply...@job.com To: so...@tenthfloor.orgmailto:so...@tenthfloor.org Subject: Position opening in your area MIME-Version: 1.0 Importance: High Content-Type: text/html Message-ID: 20110201212844.1d400396...@smtp-0.counselschambers.com.aumailto:20110201212844.1d400396...@smtp-0.counselschambers.com.au Date: Wed, 2 Feb 2011 08:28:43 +1100 Thanks Simon
RE: Sender Reputation
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Roman Gelfand Sent: Tuesday, December 21, 2010 10:29 AM To: postfix users list Subject: Sender Reputation Does anyone know of a server/software compatible with postfix that performs sender reputation query? That's a fairly general question. Reputation could refer to RBLs, whitelists, dedicated open reputation systems (e.g., http://www.dkim-reputation.org), VBR, something commercial and proprietary, etc. OpenDKIM can do two of those natively now and will have RBL querying in its next release. It also has hooks to add queries to other systems you might want to try. More help is available from the mailing lists over there (http://www.opendkim.org). -MSK
RE: Can a milter split one message into multiple messages?
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jack Bates Sent: Thursday, November 18, 2010 3:33 PM To: postfix-users@postfix.org Subject: Can a milter split one message into multiple messages? Can a milter split one message with multiple RCPT into multiple messages, each with one RCPT and different return addresses? The only way to do that is to delete all of the recipients you don't want from the main message (M) and then create a new message (M') with the rest of the recipients, and inject it whatever way you want (pipe to a postfix/sendmail instance, SMTP, etc.). Milter doesn't have a split envelope primitive. I started writing a milter to rewrite the envelope from and the From: header such that messages to each different RCPT have different return addresses Works for messages with one RCPT, but to handle messages with multiple RCPT, I need to transform it to multiple messages, so they can each have different return addresses In your case, you'll want to remove all the recipients, change the envelope sender for the remaining one, and then iterate through the rest creating clones of the message for each remaining recipient, each with a different envelope sender. That means a pipe-pipe-fork-close-close-exec (and probably some dup2s) for all recipients but the first one, with arguments set to change the envelope as appropriate, then feed it the message, close the pipes and wait for status from the child... and all the while the thread managing the original client connection is waiting for that mess to complete strolling towards a timeout. You can parallelize a lot of that, or you can use SMTP to serialize it to keep the forking and descriptor use down, but you still need to collect all the results and figure out what to return for the one whose SMTP reply you still control. There are a lot of places where things can go wrong, and you need to recover in each case as gracefully as possible. It's messy. -MSK
RE: What's done with malformed headers
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Tuesday, September 28, 2010 9:52 PM To: Postfix users Subject: Re: What's done with malformed headers The first line that is not a header is considered to be part of the message body. Postfix may or may not prepend a blank line to this non-header line (it always, did but then it was found that it is better not to insert a blank line in malformed attachments. As of 20070112 Postfix inserts the missing blank line only after the primary message header). Does this go for a header field in which there's a space between the name and the colon as well? For example: MIME-Version : 1.0 Sendmail, for example, corrects this and accepts it without starting the body there. I'm collecting enough of these results from open source and commercial MTAs alike that I'll probably seek to publish a best current practices about it. Thanks, -MSK
What's done with malformed headers
(If this would be better asked on postfix-devel, let me know and I'll repost it there.) What does Postfix do with a message that has a malformed header? If for example there's a header that's found to contain a line whose first character is alphanumeric (thus not a continuation) but contains no colon, is this treated as a header field, or does this cause the header to end and the body to begin, or something else? I'm pretty sure sendmail, for example, ends the header there and begins the body such that the malformed line is the first line of the body, but I'm wondering what postfix does. If there's consensus among popular MTAs about what to do, maybe this should be documented someplace more formally. Thanks, -MSK
RE: What's done with malformed headers
No, I didn't test it, because I don't have postfix installed anywhere here. But even testing it doesn't mean my experiment nailed down the actual source code logic or the background for it, hence the question. The absence of consensus in RFCs to date doesn't prevent the publication of a best current practice, which is what I was getting at if one could collect data from several popular open source and commercial MTAs and find a common decision about this or other issues. -MSK From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Jeroen Geilman Sent: Tuesday, September 28, 2010 3:31 PM To: postfix-users@postfix.org Subject: Re: What's done with malformed headers On 09/28/2010 10:45 PM, Murray S. Kucherawy wrote: (If this would be better asked on postfix-devel, let me know and I'll repost it there.) What does Postfix do with a message that has a malformed header? If for example there's a header that's found to contain a line whose first character is alphanumeric (thus not a continuation) but contains no colon, is this treated as a header field, or does this cause the header to end and the body to begin, or something else? Did you test it ? It's trivial to test with telnet. Postfix silently starts the body of the mail at the first non-header. I'm pretty sure sendmail, for example, ends the header there and begins the body such that the malformed line is the first line of the body, Postfix emulates sendmail behaviour to an uncanny degree, then. If there's consensus among popular MTAs about what to do, maybe this should be documented someplace more formally. The relevant RFCs contain useful information, the most telling of which is that the debate on what to do with malformed mail has not abated since the inception of SMTP in the late 70s. This means that there is no consensus - there are too many differing opinions. Postfix obviously falls squarely on the side of don't drop malformed mail unless it is technically undeliverable, which I find not unreasonable. -- J.
