Re: Best Practice for (not)allowing spoofed MAIL FROM addresses
On 22.12.2011 05:26, John Hinton wrote: One thing about email. There are NO hard rules beyond the RFCs and even those are badly abused on many fronts these days. Exceptions abound! the RFCs where written in times where we had not 13 Mio. Spammails each year filtered out and you have to accept well known pratices which are more strict then the RFCs or live with the fact that your mails are rejected on many servers - you have the choice there are also no hard rules about PTR-records of a mailserver does not change the fact that we and many others are blocking dynaddr-ip.your-provider.com because if someone decides to setup a mailserver he should be smart enough to consider a in both directions resolving DNS record why? becasue 99.999% of scuh ip-addresses is spam and the rest ignorant admins which learn it the hard way signature.asc Description: OpenPGP digital signature
Re: Best Practice for (not)allowing spoofed MAIL FROM addresses
On 22.12.2011 04:24, Richard Damon wrote: I also have one web hosting provider that basically does NOT provide outgoing SMTP service, they specifically state that they expect you to be using your ISPs SMTP server to be sending out your email. (They do provide a very throttled outgoing SMTP server if you really need it). no it is not this way for such cases we use sender dependent-relayhosts with authentication in our admin-backend, so WE NEVER directly submit mail with foreign senders, the customer can use our server and we do not break SPF In this environment, for an ISP to say that your outgoing emails must be from their domain, would be unacceptable, and cause a loss of business. and that is way ISPs often blacklisted and in some baclklists even CUSTOMERS of this ISP which does not show any reaction to complaints because they could chosse one who does ISP and would be unacceptable is somehow dumb because you are not realizing that this is a no-go - why? because if ONE customer is infected by malware this starts to send with spoofed senders and burn down the reputation of this poorly setup host - so who wil send about servers the half world throws away mails from them? if i have a domain i have a mailserver respsonsible for this domain if i want to send mails with f...@mydomain.tld i have to use this server there is no if and but, accept it or live with the problems signature.asc Description: OpenPGP digital signature
Deviding relay for internal and external mail
Hi List, I have a postfix server currently relaying all mails to our ISP mailsserver. As we had a crash in one of our big services, our ISP mailserver saw this extensivated traffic as spam (due to reputaions based filtering) and blacklisted my postfix relayhost...:-(! I have double-checked that we are not spamming, and we are only sending to internal or known vendor emails. As 99,96% of all our mail is to internal users (*@internal_mail.com), I would like to relay these directly to our official mailserver, and still keep relaying external mails (anything but *@internal_mail.com) to our ISP mailserver. Is it possible to do this in postfix, or can I only have 1 relayhost configured at a time ? If possible - how can this be done. Thanks in advance :-) ! ~maymann
Re: Deviding relay for internal and external mail
On Thursday 22 December 2011 03:39:39 Michael Maymann wrote: As 99,96% of all our mail is to internal users (*@internal_mail.com), I would like to relay these directly to our official mailserver, and still keep relaying external mails (anything but *@internal_mail.com) to our ISP mailserver. Is it possible to do this in postfix, or can I only have 1 relayhost configured at a time ? If possible - how can this be done. http://www.postfix.org/transport.5.html It's a fairly simple use of transport_maps: main.cf: transport_maps = hash:$config_directory/transport # leave your relayhost intact, assuming they have fixed the problem $config_directory/transport: # changed your example to example.com example.com smtp:example.com This does MX lookup for 'example.com' and uses the smtp(8) client to send to the MX host[s] on port 25. Note, this will not work if your outbound port 25 is blocked, and it might require whitelisting by the destination hosts, e.g., if you are in a dynamic IP range and they're using Spamhaus Zen or the like for blocking of zombies. In the case of blocked port 25, you might need this instead: example.com smtp:[host.example.com]:587 No MX lookup is done, only a hostname (A/) lookup of host.example.com, and delivery will be done on port 587. This might require some form of authentication for you on host.example.com. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: postfix devnull mailbox
On 12/21/2011 5:30 PM, Peter wrote: On 22/12/11 04:56, Stan Hoeppner wrote: or discarded. There is nothing more frustrating than trying to figure out why your emails are not going through to your customers than when they are accepted for delivery and *not* delivered. I have very little patience for anyone who insists on doing this. That's because you're confusing discarding spam with discarding legit mail. Maybe your spam filters or your own special A/S sauce simply suck? The world is shades of grey Peter, not black and white. SMTP RFCs even have grey areas Peter. I believe they are worded as may instead of should. Yes, and the world is full of email admins who don't know what they're doing, what was your point again? The LKML list manager, and many others across the globe, treat 5xx rejections of their list mail as bounces, and unsub members after a given threshold, 3 IIRC in the case of LKML lists (of which there are many dozen, 4 which I sub). I was told I must simply eat the spam along with the rest, or not participate. Yes, this is a stupid draconian policy, but I must live by their rules, or not participate. Thus, I DISCARD most of the spam from such lists instead of eating it, then manually deleting it, or sorting it to a spam folder and then deleting it as you apparently do. Why do all the extra work when a DISCARD does it for me with zero fuss? This is why I said the world is shades of grey Peter. In some circumstances DISCARD simply works, and is a better option than anything else, including the swallow/regurgitate/spit routine that you preach here. -- Stan
Re: Body checks and content-types
On 12/21/2011 11:32 PM, Alex wrote: Hi all, I have a fedora15 install with postfix-2.8.7, and have a variation of spam that I'd like to block outright using a body check. I'm trying to figure out why one of my body checks isn't working. I have the following in my body_checks.pcre file for the patterns I've found: /^Click here to see the attached photos\\/a\$/ REJECT /Click here to see the attached video/ REJECT I must be missing something with how body checks work. Perhaps as it relates to encoded mail? Is there an equivalent to $mime_header_checks for body checks, or is that not my problem? There is this content-type section involving the pattern to be found: --d058b513d2762cc0c3fbe363 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit bspan style=font-size: 26pt; a alt=wr426lbdi6hxp6my9em asackcgcqa9aw2uq9oyp b99m88wql4kh9hkw799f id=pgl2zds4k84pjgmoj1q nc9fttm7dfdi3ttdjqu1 href=d71b27vc8t0il7.xm1.me/sd_res...@cs.example.com/hicy jfazkmhacdbm27ks0r_ViewMsg Click here to see the attached photos/a --d058b513d2762cc0c3fbe363-- I've also included the whole message on pastebin: http://pastebin.com/raw.php?i=p59KJmL5 I've read the filter README, which says to avoid using body checks for junk mail. Should I just instead create a spamassassin poison pill rule for this text, and just immediately convert the message to spam instead of trying to reject it before it's queued by postfix? Is there a way to measure the overhead I've created by the hundred or so other body checks I have in place, to see if it has significantly affected performance on my system? Can someone point me to how to properly reject messages with this content? Thanks, Alex body_checks works on single line raw body content. No mime decoding or anything. If your body check doesn't match, it's probably because the raw mail doesn't actually contain what you think it does. Test your patterns with postmap -q - pcre:body_checks_file raw.mail.file The way you view the file can affect what you see, so that what you see might not be what's actually in the file. For example, the view message source function in some mail readers may not actually display the raw message. Some editors may mangle output also. Best to use vi on the message storage file, or postcat on a postfix queue file. Easiest way to check overhead is to disable body_checks and measure the difference. Excessive CPU used by the postfix cleanup process is also a good indicator of too many body checks. In general, don't use body_checks for stuff that is matched only occasionally. Use SpamAssassin for that. -- Noel Jones
Loadbalancing+failover solution
Hi List, I would like to setup a stable and reliable mailrelay solution based on PostFix, that is both redundant and could share the load between 2 physical servers. How is this done best...? thoughts/documentation/howtos are very welcome...:-) Thanks in advance :-) ! ~maymann
Howto forward local mail from all my LDAP-users on all my linuxboxes to their outlook email-accounts
Hi List, I also would like to forward local mail from all my LDAP-users (e.g. maymann) on all my linuxboxes to their outlook email-accounts (e.g michael.maym...@domain.com). Anyone with a working howto for this? Thanks in advance :-) ~Maymann
Re: Loadbalancing+failover solution
Am 22.12.2011 19:01, schrieb Michael Maymann: Hi List, I would like to setup a stable and reliable mailrelay solution based on PostFix, that is both redundant and could share the load between 2 physical servers. How is this done best...? thoughts/documentation/howtos are very welcome...:-) Thanks in advance :-) ! ~maymann the cheap way ,have 2 equal weight mx records, i ve seen this outside, not sure if you may run in problems with that, better way, use some loadbalancers before postfix, search the list archive about it as in real world , there is no best, there is only a best what fits to your needs -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: problem with dspam
On Tue, 20 Dec 2011, fakessh @ wrote: hello list hello geek hello guru hello Fu I have done tests on my smtp server used to dspam. after problems of housing road I realized that dspam removes Return-Path header my emails are then intercepted as spam. I have not found a solution to my problem please help me i use a latest stable postfix release with other tools sincerely your -- http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting Hi Problem usually occur when you run dspam from pipe, and my guess is that you do so. Consider switch to daemon mode/lmtp whish in many cases solv the problem, However if need to run from command line you might try this. dspam unix - n n - 10 pipe flags=Ru user=dspam argv=/usr/bin/dspam --client --deliver=spam,innocent --user $user --mail-from=$sender --rcpt-to $recipient -o destination_recipient_limit=1 good luck Andreas
Re: problem with dspam
Andreas Berton: Problem usually occur when you run dspam from pipe, and my guess is that you do so. Consider switch to daemon mode/lmtp whish in many cases solv the problem, However if need to run from command line you might try this. dspam unix - n n - 10 pipe flags=Ru user=dspam argv=/usr/bin/dspam --client --deliver=spam,innocent --user $user --mail-from=$sender --rcpt-to $recipient -o destination_recipient_limit=1 Per-destination recipient limits are implemented by the queue manager, so this should be specified in main.cf as: /etc/postfix/main.cf: dspam_destination_recipient_limit=1 Wietse
Re: problem with dspam
On Thu, 22 Dec 2011, Wietse Venema wrote: Andreas Berton: Problem usually occur when you run dspam from pipe, and my guess is that you do so. Consider switch to daemon mode/lmtp whish in many cases solv the problem, However if need to run from command line you might try this. dspam unix - n n - 10 pipe flags=Ru user=dspam argv=/usr/bin/dspam --client --deliver=spam,innocent --user $user --mail-from=$sender --rcpt-to $recipient -o destination_recipient_limit=1 Per-destination recipient limits are implemented by the queue manager, so this should be specified in main.cf as: /etc/postfix/main.cf: dspam_destination_recipient_limit=1 Wietse I saw that after sending it, wasn't suppose to me there. Thank you for the correction Wietse. andreas
Re: postfix devnull mailbox
On 23/12/11 01:53, Stan Hoeppner wrote: On 12/21/2011 5:30 PM, Peter wrote: There is nothing more frustrating than trying to figure out why your emails are not going through to your customers than when they are accepted for delivery and *not* delivered. I have very little patience for anyone who insists on doing this. That's because you're confusing discarding spam with discarding legit mail. No. Maybe your spam filters or your own special A/S sauce simply suck? There is no such thing as a 100% accurate SPAM filter. The LKML list manager, and many others across the globe, treat 5xx rejections of their list mail as bounces, and unsub members after a given threshold, 3 IIRC in the case of LKML lists (of which there are many dozen, 4 which I sub). As they should, they risk being flagged as spammers themselves if they continue to try to deliver to email address that have bounced or rejected. I was told I must simply eat the spam along with the rest, or not participate. Yes, this is a stupid draconian policy, but I must live by their rules, or not participate. You won't actually be rejecting emails from these (unless your MTA is mis-configured) because they are all coming from a legitimate sender. The best you can hope for is to mark them as SPAM based on the content in which case they should be delivered to a Spam folder (which would not trigger an unsub). Thus, I DISCARD most of the spam from such lists instead of eating it, then manually deleting it, or sorting it to a spam folder and then deleting it as you apparently do. Why do all the extra work when a DISCARD does it for me with zero fuss? Again, see false positives. They do happen, no matter how good your filters are. This is why I said the world is shades of grey Peter. Yes, and some emails may look like spam to your filters but actually aren't. When you take the draconian solution of discarding everything that looks like spam then you run the risk of missing important emails. Oh, and as for the RFCs, have a look at RFC 5321: 4.2.5. Reply Codes after DATA and the Subsequent CRLF.CRLF When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with CRLF.CRLF, it accepts responsibility for: o delivering the message (if the recipient mailbox exists), or o if attempts to deliver the message fail due to transient conditions, retrying delivery some reasonable number of times at intervals as specified in Section 4.5.4. o if attempts to deliver the message fail due to permanent conditions, or if repeated attempts to deliver the message fail due to transient conditions, returning appropriate notification to the sender of the original message (using the address in the SMTP MAIL command). ...which one of the above says it can drop email without delivering it? Peter
Re: postfix devnull mailbox
On Fri, 2011-12-23 at 12:10:10 +1300, Peter wrote: On 23/12/11 01:53, Stan Hoeppner wrote: On 12/21/2011 5:30 PM, Peter wrote: There is nothing more frustrating than trying to figure out why your emails are not going through to your customers than when they are accepted for delivery and *not* delivered. I have very little patience for anyone who insists on doing this. That's because you're confusing discarding spam with discarding legit mail. No. ... Because this thread has veered off into a general discussion about mail operation/policy, would you consider taking it off-list or to a more appropriate forum, e.g. the mailop list? -- Sahil Tandon
Re: postfix devnull mailbox
On Thu, 22 Dec 2011, Sahil Tandon wrote: Because this thread has veered off into a general discussion about mail operation/policy, would you consider taking it off-list or to a more appropriate forum, e.g. the mailop list? Agreed. I'm stunned that a tongue in cheek comment of mine has resulted in a flame war. =.= -Dennis
getting emails into inbox
Hi, We have been using the same mail server for a long time with the same IP. It relays the email for several webservers and of course all of our email. Yet, lately (maybe the last month or so) I have been getting a lot of complaints about their emails not being delivered and sending the same email via yahoo it gets through. I have been considering sending the email to google for relay, but is this even an option? Do we need to implement outgoing spam filtering? Thanks, Al
Re: Best Practice for (not)allowing spoofed MAIL FROM addresses
On 12/22/11 3:59 AM, Reindl Harald wrote: On 22.12.2011 04:24, Richard Damon wrote: I also have one web hosting provider that basically does NOT provide outgoing SMTP service, they specifically state that they expect you to be using your ISPs SMTP server to be sending out your email. (They do provide a very throttled outgoing SMTP server if you really need it). no it is not this way for such cases we use sender dependent-relayhosts with authentication in our admin-backend, so WE NEVER directly submit mail with foreign senders, the customer can use our server and we do not break SPF So where should I have submitted the email I described? Remember, I was describing a case where example.org was on a low cost hosting plan with very limited outbound SMTP availability. Are you going to require that ALL host providers MUST provide unlimited sender dependent-relayhosts with authentication for every domain that is hosted on their machine? (Who are you expecting to pay for this service), or are you going to say that small non-profits like this are going to be required to pay significantly more to get hosting plans that support this? Note that currently it is quite possible that the non-profit to be using 0 cost hosting that is being donated by someone on their hosting plan (I know I donate space to several non-profits on my personal web site), so raising the requirements may have a large impact on availability to these small organizations. In this environment, for an ISP to say that your outgoing emails must be from their domain, would be unacceptable, and cause a loss of business. and that is way ISPs often blacklisted and in some baclklists even CUSTOMERS of this ISP which does not show any reaction to complaints because they could chosse one who does ISP and would be unacceptable is somehow dumb because you are not realizing that this is a no-go - why? because if ONE customer is infected by malware this starts to send with spoofed senders and burn down the reputation of this poorly setup host - so who wil send about servers the half world throws away mails from them? Yes, the ISP needs to be responsive. Just blocking emails not from the ISP's domain is NOT enough to keep them from being a spam source, after all, the spam bot could always NOT fake the sender and still send out all the spam, it just make it easier for people to know who to complain to, but if they won't respond that doesn't matter. If they are responsive, it doesn't really matter if they allow responsible fake sender emails. They can do a few basic checks like check the SPF record of the domain in the From field to make sure they are allowed to send such an email. It also may make sense to apply a rate limit to foreign senders that haven't been pre-registered (and maybe even to drop that rate under suspicious activity like sending with a sender that violates SPF). if i have a domain i have a mailserver respsonsible for this domain if i want to send mails with f...@mydomain.tld i have to use this server there is no if and but, accept it or live with the problems Until EVERY domain supports this, it is NOT a case of being poorly setup for an ISP to support its customers. -- Richard Damon
