Re: Avoiding (trivial) spoofed mail from
mouss escribió: Roman Medina-Heigl Hernandez a écrit : Why is the mail not being rejected due to reject_unauthenticated_sender_login_mismatch? I must have a silly bug but I couldn't find it... :-( I got to solve it by: smtpd_sender_login_maps = $virtual_mailbox_maps do not reuse maps this way. use a script to generate each map instead (or use note that smtpd_sender_login_maps returns one or more logins, while virtual_mailbox_maps returns the path to the mailbox. Since I'm using Cyrus LMTP, I don't have the path to mailbox variable, so I could return whatever in $virtual_mailbox_maps. What I did was to return the email address (which in turn corresponds to the SASL login). So now it's perfectly compatible to use the same Mysql map for both variables. I mean: hsnew:/etc/postfix# cat /etc/postfix/vuser.mysql # Virtual users (Mysql) hosts = unix:/var/run/mysqld/mysqld.sock user= postfix password= xx dbname = postfix query = select user from user where user = '%s' And in main.cf: virtual_mailbox_maps = mysql:/etc/postfix/vuser.mysql smtpd_sender_login_maps = mysql:/etc/postfix/vuser.mysql Ok now? :-) Cheers, -r
Re: Avoiding (trivial) spoofed mail from
On 3-Dec-2008, at 15:44, DJ Lucas wrote: LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. No there isn't. AFAIK, unless I'm misunderstanding something, the rest of your message simply puts what I said above in different terms and agrees entirely. **my mom** was in the From header...nowhere else. The From header can be changed up to say that it came from somebody else. I don't care about that. The check in question is in the smtp transaction, not the data. Ah, I thought you were complaining about mismatches in the From_ and the From: rereading Yes, we agree entirely. -- Dinosaurs are attacking! Throw a barrel!
Re: Avoiding (trivial) spoofed mail from
On 3-Dec-2008, at 16:53, mouss wrote: DJ Lucas a écrit : LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. No there isn't. Yes. there is;-p can we agree to disagree or do we need to contact the UNO? Maybe. The FROM_ (the envelope from, the SMTP transaction from, etc) should always be the actual source of the message. If acme.tld is sending a message on behalf of [EMAIL PROTECTED] then the FROM_ has to be acme.tld. The From: should be [EMAIL PROTECTED] there is no reason to lie in the SMTP transaction about who you are, and spoofing that is going to be a spam-tag to many servers. I touched on this in a previous message, the FROM_ and the Received headers should match up in some way, even if 'matched up' is simply an SPF match for the FROM_ -- Well I've seen the Heart of Darkness/Read the writing on the wall/an the voice out in the desert/Was the voice out in the hall
Re: Avoiding (trivial) spoofed mail from
DJ Lucas wrote: Noel Jones wrote: Very likely there are other, better ways to combat this spam. Look for other traits you can use to reject it. I am, by no means, anything even close to expert WRT the whole SMTP process, but, I do think that I can provide (or at least what I believe to be) a valid, albeit opinionated, counter argument. See below. some things to look for: - client listed on some RBL - client name that looks dynamic - using your domain or IP as HELO - unusual headers - body text unlikely to be found in legit mail If that doesn't help, consider adding SpamAssassin and/or ClamAV. From my POV, this one check saves me a small few (100, 200?) DNS/RBL lookups per month and a few CPU cycles by not getting to header checks, body checks, and finally SA (which is probably the most expensive check in the stack, followed immediately by virus scanning). I can probably parse my logs and give a real number, but it would seem insignificant to those running large servers. It is my _choice_ to be as efficient as possible. IMO Please correct me if I've made an invalid assumption (but do take notice of the IMO qualifier!) I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? It is plain irresponsible, even if allowed by RFC. Even more so given that most (all?) mail clients will honor the from header and display it, in big, bright, flashy, bold text, in a prominent location for the end user to see (and reply to). Maybe I've missed something, but I really cannot find a good reason to allow it. Even the BlackBerry example given above is an example of poor practice in my opinion, but it can be an ALLOWed exception if it is out of your control. But that is all a matter of principal, not a technical reason. The technical reason (minor increase in efficiency) was above, but I also provide one more weak technical argument. Another possible (but pretty unlikely now days) side effect of allowing such message mangling to occur is that it could lead to backscatter if an intermediate server is mis-configured. That is not my problem if it is 'properly' denied at the door and not allowed (either direction) by my server. /IMO I agree with you. But the reality is that a large number of legit senders will use the recipient or some other valid user in your domain as the envelope sender. It's perfectly fine for you to have a policy that doesn't allow this, but be aware that there are still some babies in that bathwater. That particular Postfix directive was created for some reason, so somebody, somewhere must agree. Anyway, bottom line, it is my server. I try to protect my small number of users from the outside world (and themselves) as best I can. If they don't like my policy, they can find another place to put their mail. Others may not be lucky enough to be able to enforce such a policy, as the counter argument would be to find a less rigid admin. ;-) What is 'acceptable' has to be determined on a site by site basis. If it works for this site...great! If it doesn't, then get rid of it. I agree completely, I just want you to understand the implication of such a policy. It may work well for you, it may not. Depends greatly on your users and how much collateral damage they are collectively willing to accept, and your authority to enforce such a policy. I hope that came off as a constructive, alternative vantage point rather than being argumentative. :-) -- DJ Lucas Yes, that's what a discussion is all about. -- Noel Jones
Re: Avoiding (trivial) spoofed mail from
On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. First off, the envelope from is not FOR the user, it's for the mailserver. This address should always be where the 'physical' delivery of the message is originating. The From header is the PERSON that initiated the message. These are often the same, but not always. A perfect example is my mom sends out electronic cards from Jacquie Lawson1 which arrive with headers like this: Return-Path: [EMAIL PROTECTED] Received: from iport3.jacquielawson.com (iport3.jacquielawson.com [64.14.122.52]) by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F for [EMAIL PROTECTED]; Thu, 27 Nov 2008 02:27:05 -0700 (MST) Date: Thu, 27 Nov 2008 04:27:02 -0500 X-AG-MIPS: ag867 Sender: [EMAIL PROTECTED] From: **my mom** This is perfectly OK. In fact, this is exactly how this should be handled. This method is also used when someone is sending, for example, a petition request where they've 'signed' and want to let others know to sign also. Many pages (particularly political ones) have these sorts of tell your friends links and they to will use the person's email/name as the from and their own server info for the envelope. I would be far more likely to take a look at the FROM_ and compare it to the Received header than with the From: header, as I think that is far more likely to spot spam. Extending this to a physical letter situation it would be like Barack Obama's campaign sending me a letter that was signed by, say, my mom. She wrote the letter and signed it, but the campaign office mailed it in their own envelope. Seems fine to me. If they don't like my policy, they can find another place to put their mail. Others may not be lucky enough to be able to enforce such a policy, as the counter argument would be to find a less rigid admin. ;-) What is 'acceptable' has to be determined on a site by site basis. If it works for this site...great! If it doesn't, then get rid of it. Just so you know that there are common and legitimate uses for this, and that you will lose valid emails that, presumably, your users actually want. And if you are rejecting them, do your users know they are missing those emails? I mean, are they informed enough that they can make a real choice about getting MOST of their email from you or getting ALL of their email from someone else? 1 I have no connection with Jacquie Lawson. I'm not even a customer, I am merely a recipient. I do like the cards though. -- [TN]FBMachine i got kicked out of Barnes and Noble once for moving all the bibles into the fiction section
Re: Avoiding (trivial) spoofed mail from
LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. First off, the envelope from is not FOR the user, it's for the mailserver. This address should always be where the 'physical' delivery of the message is originating. The From header is the PERSON that initiated the message. These are often the same, but not always. A perfect example is my mom sends out electronic cards from Jacquie Lawson1 which arrive with headers like this: Return-Path: [EMAIL PROTECTED] Received: from iport3.jacquielawson.com (iport3.jacquielawson.com [64.14.122.52]) by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F for [EMAIL PROTECTED]; Thu, 27 Nov 2008 02:27:05 -0700 (MST) Date: Thu, 27 Nov 2008 04:27:02 -0500 X-AG-MIPS: ag867 Sender: [EMAIL PROTECTED] From: **my mom** I don't see how this particular case would be affected. The only forged part was in the header that I can see from your example, not the actual MAIL FROM during the initial part of the SMTP conversation. Currently I have our configuration set to reject mail claiming a MAIL FROM that originates in our domain if the session has not been authenticated or coming from the local network. Example where MAIL FROM is not forged, but From part of header is: $ telnet mail1.omitted_for_privacy.com 25 Trying x.x.x.x... Connected to mail1.omitted_for_privacy.com. Escape character is '^]'. 220 mail1.omitted_for_privacy.com ESMTP EHLO omitted_for_privacy.com 250-mail1.omitted_for_privacy.com 250-PIPELINING 250-SIZE 2147483647 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM:[EMAIL PROTECTED] 250 2.1.0 Ok RCPT TO:[EMAIL PROTECTED] 250 2.1.5 Ok DATA 354 End data with CRLF.CRLF From: [EMAIL PROTECTED] Subject: proof that only the mail from portion is rejected This email should be accepted by our mail server . 250 2.0.0 Ok: queued as 241056A006F QUIT 221 2.0.0 Bye Connection closed by foreign host. Example where MAIL FROM is forged: $ telnet mail1.omitted_for_privacy.com 25 Trying 12.48.244.4... Connected to mail1.omitted_for_privacy.com. Escape character is '^]'. 220 mail1.omitted_for_privacy.com ESMTP EHLO judelawfirm.com 250-mail1.omitted_for_privacy.com 250-PIPELINING 250-SIZE 2147483647 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM:[EMAIL PROTECTED] 250 2.1.0 Ok RCPT TO:[EMAIL PROTECTED] 554 5.7.1 [EMAIL PROTECTED]: Sender address rejected: Not authenticated QUIT 221 2.0.0 Bye Connection closed by foreign host. This is perfectly OK. In fact, this is exactly how this should be handled. I agree completely, I do not think it's OK to forge the MAIL FROM portion of the SMTP conversation though. I think this is what DJ Lucas was getting at. This method is also used when someone is sending, for example, a petition request where they've 'signed' and want to let others know to sign also. Many pages (particularly political ones) have these sorts of tell your friends links and they to will use the person's email/name as the from and their own server info for the envelope. I would be far more likely to take a look at the FROM_ and compare it to the Received header than with the From: header, as I think that is far more likely to spot spam. Extending this to a physical letter situation it would be like Barack Obama's campaign sending me a letter that was signed by, say, my mom. She wrote the letter and signed it, but the campaign office mailed it in their own envelope. Seems fine to me. If they don't like my policy, they can find another place to put their mail. Others may not be lucky enough to be able to enforce such a policy, as the counter argument would be to find a less rigid admin. ;-) What is 'acceptable' has to be determined on a site by site basis. If it works for this site...great! If it doesn't, then get rid of it. Just so you know that there are common and legitimate uses for this, and that you will lose valid emails that, presumably, your users actually want. And if you are rejecting them, do your users know they are missing those emails? I mean, are they informed enough that they can make a real choice about getting MOST of their email from you or getting ALL of their email from someone else? 1 I have no connection with Jacquie Lawson. I'm not even a customer, I am merely a recipient. I do like the cards though. At this point I think there is some confusion about what is being stated is acceptable and what is not.
Re: Avoiding (trivial) spoofed mail from
LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. No there isn't. AFAIK, unless I'm misunderstanding something, the rest of your message simply puts what I said above in different terms and agrees entirely. **my mom** was in the From header...nowhere else. The From header can be changed up to say that it came from somebody else. I don't care about that. The check in question is in the smtp transaction, not the data. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean.
Re: Avoiding (trivial) spoofed mail from
DJ Lucas a écrit : LuKreme wrote: On 2-Dec-2008, at 20:21, DJ Lucas wrote: I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? Sure there is. No there isn't. Yes. there is;-p can we agree to disagree or do we need to contact the UNO? AFAIK, unless I'm misunderstanding something, the rest of your message simply puts what I said above in different terms and agrees entirely. **my mom** was in the From header...nowhere else. The From header can be changed up to say that it came from somebody else. I don't care about that. The check in question is in the smtp transaction, not the data. -- DJ Lucas
Re: Avoiding (trivial) spoofed mail from
DJ Lucas escribió:
Return-Path: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
...
Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
for [EMAIL PROTECTED]; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
From: RoMaNSoFt [EMAIL PROTECTED]
Maybe I'm incorrect, but I believe there was a subtle misunderstanding
in the above conversation. The From: header is not the same as MAIL
FROM: command in smtp transaction. MAIL FROM for this message was
[EMAIL PROTECTED] Feel fee to find that message in your logs and
Thank you for the correction, you are right: my example is wrong but that
doesn't change the fact we were discussing since Noel and I were always
referring to the mail from (i.e. the sender). If some silly ticket system
spoofs the From header, there is a good chance that it spoofs the mail
from too...
verify. Anyway, the Postfix directive you are looking for is
reject_unauthenticated_sender_login_mismatch.
http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
Yes, I think that's the directive I was looking for.
That said, cheap web scripts often do use the recipient's address in the
transaction. Latest complaint I had was from some star rewards thing
for frequent visits to a restaurant (for which I promptly replied:
choose a different restaurant ;-) ).
Take the following two manual transactions as an example with the smtpd
sender restriction above (only slightly altered to avoid giving away
unnecessary info and posting a real address in plain text on the internet):
[EMAIL PROTECTED] ~]# telnet mail.lucasit.com 25
Trying 192.168.xxx.xxx...
Connected to mail.lucasit.com.
Escape character is '^]'.
220 postal.lucasit.com ESMTP Postfix
ehlo somehost.lucasit.com
250-postal.lucasit.com
250-PIPELINING
Isn't a good idea to disable pipelining? (many people recommends it to
reduce spam).
250-SIZE 1024
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: [EMAIL PROTECTED]
250 2.1.0 Ok
RCPT TO: [EMAIL PROTECTED]
553 5.7.1 [EMAIL PROTECTED]: Sender address rejected: not logged in
Nice. That's what I'd like to set-up. Nevertheless, I tried to reproduce in
a test system, with no luck :-(. It should be trivial, but I cannot find
the error. Could you help me?
My setup is quite simple (using virtual domains and Amavis to mark
virus/spam messages):
hsnew:/etc/postfix# postconf -n
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
delay_warning_time = 4
disable_vrfy_command = yes
mail_name = mxhs
mailbox_command = procmail -a $EXTENSION
message_size_limit = 28311552
mydestination = $myhostname localhost localhost.$mydomain
myhostname = hsnew.rs-labs.es
mynetworks = 127.0.0.2, 127.0.0.3
myorigin = $myhostname
recipient_delimiter = +
relay_domains = hash:/etc/postfix/listas hash:/etc/postfix/mxbackup
relocated_maps = hash:/etc/postfix/relocated
show_user_unknown_table_name = no
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noplaintext
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
permit_mynetworks, permit_sasl_authenticated,
reject_unauthenticated_sender_login_mismatch,check_recipient_access
hash:/etc/postfix/recipient_access_non_trusted, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/listas
virtual_alias_maps = hash:/etc/postfix/valias
virtual_mailbox_domains = hash:/etc/postfix/vdomain
virtual_mailbox_maps = hash:/etc/postfix/vuser
virtual_transport = lmtp:unix:/private/cyrus
hsnew:/etc/postfix# cat vuser
[EMAIL PROTECTED]whatever
hsnew:/etc/postfix# cat vdomain
rs-labs.es whatever
hsnew:/etc/postfix#
From another host (not trusted), I'm sending a very simple mail:
[EMAIL PROTECTED]:/tmp# cat mail
helo k
mail from:[EMAIL PROTECTED]
rcpt to:[EMAIL PROTECTED]
data
subject: prueba
.
quit
[EMAIL PROTECTED]:/tmp# nc hsnew.rs-labs.es 25 mail
220 hsnew.rs-labs.es ESMTP Sendmail 8.14.2/8.14.1
250 hsnew.rs-labs.es
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with CRLF.CRLF
250 2.0.0 Ok: queued as 3A4F6982AA
221 2.0.0 Bye
[EMAIL PROTECTED]:/tmp#
My receiving MTA logs the following:
Dec 2 16:34:12 hsnew postfix/smtpd[3697]: connect from
207-150-162-19.static.sagonet.net[207.150.162.19]
Dec 2 16:34:12 hsnew
Re: Avoiding (trivial) spoofed mail from
Roman Medina-Heigl Hernandez escribió:
DJ Lucas escribió:
Return-Path: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
...
Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1])
by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376
for [EMAIL PROTECTED]; Fri, 28 Jul 2006 04:10:09 +0100 (BST)
From: RoMaNSoFt [EMAIL PROTECTED]
Maybe I'm incorrect, but I believe there was a subtle misunderstanding
in the above conversation. The From: header is not the same as MAIL
FROM: command in smtp transaction. MAIL FROM for this message was
[EMAIL PROTECTED] Feel fee to find that message in your logs and
Thank you for the correction, you are right: my example is wrong but that
doesn't change the fact we were discussing since Noel and I were always
referring to the mail from (i.e. the sender). If some silly ticket system
spoofs the From header, there is a good chance that it spoofs the mail
from too...
verify. Anyway, the Postfix directive you are looking for is
reject_unauthenticated_sender_login_mismatch.
http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch
Yes, I think that's the directive I was looking for.
That said, cheap web scripts often do use the recipient's address in the
transaction. Latest complaint I had was from some star rewards thing
for frequent visits to a restaurant (for which I promptly replied:
choose a different restaurant ;-) ).
Take the following two manual transactions as an example with the smtpd
sender restriction above (only slightly altered to avoid giving away
unnecessary info and posting a real address in plain text on the internet):
[EMAIL PROTECTED] ~]# telnet mail.lucasit.com 25
Trying 192.168.xxx.xxx...
Connected to mail.lucasit.com.
Escape character is '^]'.
220 postal.lucasit.com ESMTP Postfix
ehlo somehost.lucasit.com
250-postal.lucasit.com
250-PIPELINING
Isn't a good idea to disable pipelining? (many people recommends it to
reduce spam).
250-SIZE 1024
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: [EMAIL PROTECTED]
250 2.1.0 Ok
RCPT TO: [EMAIL PROTECTED]
553 5.7.1 [EMAIL PROTECTED]: Sender address rejected: not logged in
Nice. That's what I'd like to set-up. Nevertheless, I tried to reproduce in
a test system, with no luck :-(. It should be trivial, but I cannot find
the error. Could you help me?
My setup is quite simple (using virtual domains and Amavis to mark
virus/spam messages):
hsnew:/etc/postfix# postconf -n
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
delay_warning_time = 4
disable_vrfy_command = yes
mail_name = mxhs
mailbox_command = procmail -a $EXTENSION
message_size_limit = 28311552
mydestination = $myhostname localhost localhost.$mydomain
myhostname = hsnew.rs-labs.es
mynetworks = 127.0.0.2, 127.0.0.3
myorigin = $myhostname
recipient_delimiter = +
relay_domains = hash:/etc/postfix/listas hash:/etc/postfix/mxbackup
relocated_maps = hash:/etc/postfix/relocated
show_user_unknown_table_name = no
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noplaintext
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
permit_mynetworks, permit_sasl_authenticated,
reject_unauthenticated_sender_login_mismatch,check_recipient_access
hash:/etc/postfix/recipient_access_non_trusted, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/listas
virtual_alias_maps = hash:/etc/postfix/valias
virtual_mailbox_domains = hash:/etc/postfix/vdomain
virtual_mailbox_maps = hash:/etc/postfix/vuser
virtual_transport = lmtp:unix:/private/cyrus
hsnew:/etc/postfix# cat vuser
[EMAIL PROTECTED]whatever
hsnew:/etc/postfix# cat vdomain
rs-labs.es whatever
hsnew:/etc/postfix#
From another host (not trusted), I'm sending a very simple mail:
[EMAIL PROTECTED]:/tmp# cat mail
helo k
mail from:[EMAIL PROTECTED]
rcpt to:[EMAIL PROTECTED]
data
subject: prueba
.
quit
[EMAIL PROTECTED]:/tmp# nc hsnew.rs-labs.es 25 mail
220 hsnew.rs-labs.es ESMTP Sendmail 8.14.2/8.14.1
250 hsnew.rs-labs.es
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with CRLF.CRLF
250 2.0.0 Ok: queued as 3A4F6982AA
221 2.0.0 Bye
[EMAIL PROTECTED]:/tmp#
My receiving MTA logs the following:
Re: Avoiding (trivial) spoofed mail from
Roman Medina-Heigl Hernandez wrote: DJ Lucas escribió: Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] ... Received: from gangotri.ubuntu.com (localhost.localdomain [127.0.0.1]) by gangotri.ubuntu.com (Postfix) with ESMTP id 0C222318376 for [EMAIL PROTECTED]; Fri, 28 Jul 2006 04:10:09 +0100 (BST) From: RoMaNSoFt [EMAIL PROTECTED] Maybe I'm incorrect, but I believe there was a subtle misunderstanding in the above conversation. The From: header is not the same as MAIL FROM: command in smtp transaction. MAIL FROM for this message was [EMAIL PROTECTED] Feel fee to find that message in your logs and Thank you for the correction, you are right: my example is wrong but that doesn't change the fact we were discussing since Noel and I were always referring to the mail from (i.e. the sender). If some silly ticket system spoofs the From header, there is a good chance that it spoofs the mail from too... verify. Anyway, the Postfix directive you are looking for is reject_unauthenticated_sender_login_mismatch. http://www.postfix.org/postconf.5.html#reject_unauthenticated_sender_login_mismatch Yes, I think that's the directive I was looking for. That said, cheap web scripts often do use the recipient's address in the transaction. Latest complaint I had was from some star rewards thing for frequent visits to a restaurant (for which I promptly replied: choose a different restaurant ;-) ). I have been working on a similar if not the exact same problem from what I've seen in this thread. The problem being from = to address and how to stop spam that does this. My idea for a solution to this problem was to require any mail claiming to be from a local account to authenticate first when arriving from outside of the network and heading to a local mailbox. As it has already been pointed out, there are cases where you have false positives, in fact I found one yesterday with a user's blackberry setup shortly after I set it up. I'm thinking that utilizing check_client_access before check_sender_access under smtpd_recipient_restrictions and adding exceptions for these few cases is a sound solution. It's obviously not perfect because of the administration overhead of having to watch for these special circumstances. I have yet to test this. Any thoughts on this approach?
Re: Avoiding (trivial) spoofed mail from
J.P. Trosclair wrote: I have been working on a similar if not the exact same problem from what I've seen in this thread. The problem being from = to address and how to stop spam that does this. My idea for a solution to this problem was to require any mail claiming to be from a local account to authenticate first when arriving from outside of the network and heading to a local mailbox. As it has already been pointed out, there are cases where you have false positives, in fact I found one yesterday with a user's blackberry setup shortly after I set it up. I'm thinking that utilizing check_client_access before check_sender_access under smtpd_recipient_restrictions and adding exceptions for these few cases is a sound solution. It's obviously not perfect because of the administration overhead of having to watch for these special circumstances. I have yet to test this. Any thoughts on this approach? Very likely there are other, better ways to combat this spam. Look for other traits you can use to reject it. some things to look for: - client listed on some RBL - client name that looks dynamic - using your domain or IP as HELO - unusual headers - body text unlikely to be found in legit mail If that doesn't help, consider adding SpamAssassin and/or ClamAV. -- Noel Jones
Re: Avoiding (trivial) spoofed mail from
Noel Jones wrote: Very likely there are other, better ways to combat this spam. Look for other traits you can use to reject it. I am, by no means, anything even close to expert WRT the whole SMTP process, but, I do think that I can provide (or at least what I believe to be) a valid, albeit opinionated, counter argument. See below. some things to look for: - client listed on some RBL - client name that looks dynamic - using your domain or IP as HELO - unusual headers - body text unlikely to be found in legit mail If that doesn't help, consider adding SpamAssassin and/or ClamAV. From my POV, this one check saves me a small few (100, 200?) DNS/RBL lookups per month and a few CPU cycles by not getting to header checks, body checks, and finally SA (which is probably the most expensive check in the stack, followed immediately by virus scanning). I can probably parse my logs and give a real number, but it would seem insignificant to those running large servers. It is my _choice_ to be as efficient as possible. IMO Please correct me if I've made an invalid assumption (but do take notice of the IMO qualifier!) I can find absolutely no reason to inadvertently mislead, or worse, intentionally deceive the recipient by forging the envelope sender's address. In fact, the only reason I can see, is to intentionally deceive the recipient. Is there any other reason? It is plain irresponsible, even if allowed by RFC. Even more so given that most (all?) mail clients will honor the from header and display it, in big, bright, flashy, bold text, in a prominent location for the end user to see (and reply to). Maybe I've missed something, but I really cannot find a good reason to allow it. Even the BlackBerry example given above is an example of poor practice in my opinion, but it can be an ALLOWed exception if it is out of your control. But that is all a matter of principal, not a technical reason. The technical reason (minor increase in efficiency) was above, but I also provide one more weak technical argument. Another possible (but pretty unlikely now days) side effect of allowing such message mangling to occur is that it could lead to backscatter if an intermediate server is mis-configured. That is not my problem if it is 'properly' denied at the door and not allowed (either direction) by my server. /IMO That particular Postfix directive was created for some reason, so somebody, somewhere must agree. Anyway, bottom line, it is my server. I try to protect my small number of users from the outside world (and themselves) as best I can. If they don't like my policy, they can find another place to put their mail. Others may not be lucky enough to be able to enforce such a policy, as the counter argument would be to find a less rigid admin. ;-) What is 'acceptable' has to be determined on a site by site basis. If it works for this site...great! If it doesn't, then get rid of it. I hope that came off as a constructive, alternative vantage point rather than being argumentative. :-) -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean.
Re: Avoiding (trivial) spoofed mail from
Noel Jones escribió: Roman Medina-Heigl Hernandez wrote: Hello, Spammers often send (forged) mail where mail from address is the same as rcpt to address. An extension of that could be using a mail from address where src domain is one of our valid virtual domains. I can only think of 3 cases: 1) Src IP is 127.0.0.1 - Mail should pass (eg: sent by webmail, installed on the same MTA host). 2) Authenticated sender - Legit users authenticated by SASL - Should pass 3) All the rest - Should be rejected (SPAM) (assuming a simple single-MTA config, where MX -receiving mail server- is the same as MTA -outbound sending mail server-) Which is the best/preferred Postfix config to filter out that kind of spam? I have all my valid domains in: virtual_mailbox_domains = hash:/etc/postfix/vdomain The current format of /etc/postfix/vdomain is: domain1 whatever domain2 whatever So perhaps I could do somthing like: smtpd_sender_restrictions = smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, X, permit where could be some kind of check_sender_access clausule, rejecting domains listed in $virtual_mailbox_domains. How could I implement this? Is there any other preferred solution? Yes, you can use a map for this; above = check_sender_access hash:/etc/postfix/mydomains # mydomains example.com REJECT inside sender not allowed example.net REJECT inside sender not allowed ... So there is no other way to do this without having to duplicate the same/similar hash file (/etc/postfix/vdomain and /etc/postfix/mydomains). I thought perhaps it could exist some directive of the form: reject_mydestination_domain_sender or something similar to avoid duplicating domain databases ;-)). Note this will reject some legit mail. Spamassassin is probably a Could you elaborate on that legit mail cases? Examples? It's very important for me and I couldn't figure any legit cases (apart from the ones I already mentioned). better choice for filtering this type mail. If I use spamassasing for this, I have to supply my vdomains to spamassassin. Currently, I implemented a quick have in Amavis, so all domains are treated as local: @local_domains_acl = qw( . ); My Amavis/spamassasing setup is not filtering at all; it is only used for marking/scoring (adding headers to) mails (filtering is performed via Sieve, based on X-Spam-*/X-Amavis-* Headers). http://www.openspf.org/ As I said, SPF is plannified for next stage, and I'll have a look to different resources (thanks for your notes!!). Regards, -Roman
Re: Avoiding (trivial) spoofed mail from
Roman Medina-Heigl Hernandez wrote: Noel Jones escribió: You are (again) right, perhaps spamassasin is better for performing this kind of check... with the added bonus that filtered mail is not dropped, but quarantined (so you could always rescue a false negative). Do you know how well does it (SA) perform at blocking this spam case (src dom=dst dom) while recognizing legit (but nasty) notices? For the very same reason, isn't it better to let Spamassassin make intelligent SPF-checks instead of using some other policy server with Postfix? The whole idea of SpamAssassin scoring is that the spamminess of of messages comes from lots of little things - some positive scores, some negative scores - that usually adds up to something that accurately represents whether a message is spam or not. No one rule (unless it's a rare 100% guaranteed spam indicator) ever decides on its own that a message is spam. While a message might exhibit the From=To and SPF errors described above, most legit mail still wouldn't trigger enough points to get into the likely spam range. SpamAssassin itself isn't 100% accurate, but it does fairly well with a very wide range of junk. It's a good tool to use, but you need more than one tool. Selective RBLs (zen.spamhaus.org is highly recommended), ClamAV with the Sanesecurity add-on signatures, and careful postfix checks can reject a lot of spam before SpamAssassin ever sees it. It's also important to note that the settings you use depend on your user base and your goals - there is no one-size-fits-all solution, which is why you'll never see such a thing posted here. Your best bet is to lurk on the list for a while or browse the archives to learn what might work well in your situation. -- Noel Jones
