RE: [Mimedefang] OT: New Sendmail spam block
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of John Buysse > Sent: vrijdag 25 maart 2005 20:53 > To: mimedefang@lists.roaringpenguin.com > Subject: Re: [Mimedefang] OT: New Sendmail spam block > > > I am with one of the universities Ben is dealing with. I was quoting > RFC 2821, not RFC 821. We are not rejecting messages with an invalid > HELO command based on RFC 1123, as we are not verifying the the info > provided. We are rejecting messages with an invalid HELO > command based RFC 2821. Then I would say you are doing a good thing. I do the same. :) > If a remote server uses one of our IP's in the HELO > command, our servers will reject the message. I also reject on every HELO name which is in class=w (sendmail), but connects with the wrong IP (including, but not limited, to addresses which resolve to 'localhost', but are not from 127.*). Very effective, too. A lot of spammers seem to think that you will somehow give them a passepartout if only they use your hostname for HELO. ;) That logic has always escaped me; for even if I were not monitoring HELO names, connecting with such faked, local HELO names means absolutely nothing to sendmail, in terms of giving out extra credit. All a spammer really does that way, is unequivocally announce and confirm his own status as a bonafide spammer. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
On Fri, 2005-03-25 at 16:42 -0600, Les Mikesell wrote: > On Thu, 2005-03-24 at 18:34, Richard Laager wrote: > > > If he's blocking because the domain you're sending *doesn't resolve to > > the IP address of your machine*, he's broken. You *might* also be > > broken. > > Or you might be multi-homed and not changing your name to match > the interface for each conversation. Or you might be behind a NAT or PAT device. That's why I said "might". -- Richard Laager <[EMAIL PROTECTED]> Wikstrom Telecom Internet ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
On Thu, 2005-03-24 at 18:34, Richard Laager wrote: > If he's blocking because the domain you're sending *doesn't resolve to > the IP address of your machine*, he's broken. You *might* also be > broken. Or you might be multi-homed and not changing your name to match the interface for each conversation. -- Les Mikesell [EMAIL PROTECTED] ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
You are neglecting section 4.1.4: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. and also the text of section 4.1.1.1 reads: In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The keyword here is SHOULD which means the client does not have to or may not be able to for some reason. I have logs of thousands of "BOGUS HELOS" and have found a great many MTAs out there do not send correctly formatted HELO/EHLO... including MS Exchange. In addition I would say at least 90% of the windows MUAs out there do not send a correctly formatted HELO/EHLO. In short, I do think if you are using the value in the HELO/EHLO string to reject messages based soley on the formatting of that value, that you are in violation of RFC 2821 section 4.1.1.1 and 4.1.4 and are going to get a great many complaints from people as to "why cant I get this message from my colleage at this institution" or "Why is my message to XX at your university rejected?" Bottom line, I have had zero false positives in my testing with bad formatted literals (bare IPs as a literal), these I reject after RCPT TO: to remain compliant and to be able to not reject abuse and postmaster messages... which by the way will also put you in violation... Rejecting the others due to them not having a FQDN that is resolvable is just asking for more work for your mail admins Did you not enable the business logic with some logging first (and no rejects) to see what impact this would have on your mail server and customer base? Jim PS: results here are from my testing here with my customer base, your results may vary. On Fri, 25 Mar 2005 12:29:46 -0500, John Buysse wrote > I am with one of the universities Ben is dealing with. I was > quoting RFC 2821, not RFC 821. We are not rejecting messages with > an invalid HELO command based on RFC 1123, as we are not verifying > the the info provided. We are rejecting messages with an invalid > HELO command based on RFC 2821. If a remote server uses one of our > IP's in the HELO command, our servers will reject the message. Our > servers will also reject the message if the value given in the HELO > command is an unqualified hostname or is not an address literal, as > stated in sections > 4.1.1.1 and 4.1.3 of RFC 2821. We are only ensuring the value given > in the HELO command is syntactically correct as stated in RFC 2821. -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
I am with one of the universities Ben is dealing with. I was quoting RFC 2821, not RFC 821. We are not rejecting messages with an invalid HELO command based on RFC 1123, as we are not verifying the the info provided. We are rejecting messages with an invalid HELO command based on RFC 2821. If a remote server uses one of our IP's in the HELO command, our servers will reject the message. Our servers will also reject the message if the value given in the HELO command is an unqualified hostname or is not an address literal, as stated in sections 4.1.1.1 and 4.1.3 of RFC 2821. We are only ensuring the value given in the HELO command is syntactically correct as stated in RFC 2821. Thanks, John Buysse David F. Skoll wrote: On Thu, 24 Mar 2005, Ben Kamen wrote: The person I've been having the problems with is quoting RFC821, but forgetting he's breaking RFC1123 which is the amendment to 821. The latest is RFC 2821. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
James Ebright wrote: > > Anyway, still sifting some of this.. maybe I will change my mind but bottom > line is.. I think your Norton product is broke! > It's not my system. It belongs to someone I help out. But as I already told the other admin - this extent, I do believe this could be done better. Most definitely. I appreciate everyone's help and insight into this. Spam has past the point of being an annoying problem. It's making the rest of us run around on these crazy sidetracks when our time is better spent on more important things. Who wants to email Bob Metcalf and get his take on when the internet will melt down THIS time? ;) -Ben ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
>From RFC2821:
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.
Looks to me that the keyword SHOULD means you do not have to if you have a
good reason not to. However, your system probably does have a meaningful
domain name and a FQDN in DNS just your MTA (Norton gateway) is not doing
the correct thing and probably needs to be behind a real MTA, thus, I do think
that your MTA is just as "non compliant" as theirs is, if not more so.
However looks like section 4.1.4 still has this text:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Which leads me to believe that in order to be fully compliant, you can not
disallow a message solely due to the HELO/EHLO that was given.
In the examples we have laid out in previous messages we took the HELO and
rejected the message based not soley on the HELO but also due to the fact that
the HELO/EHLOs were attempted header forgeries of our own known systems, or a
literal in the wrong format (e.g. no brackets) in an attempted forgery or
obfuscation. Either of which I think would satisfy the RFCs MUST NOT.
Now I did notice MD using filter_recipient(sender, et al) and using return
('REJECT', "BOGUS HELO $helo blah blah blah") will issue a 550 5.7.1
reject from the milter in the filter_recipient stage (I wait until filter
recipient as I need to skip filtering my abuse addresses, and a few other
things) which is not the 500, 501, or 502 reject as specified with a MUST in
the RFC, but.. mine is not in response to the HELO parameter either but to the
RCPT TO: command and at this point I have looked at the sender, the recipient,
a list of allowed HELOs from certain IPs (e.g. my mail servers), the format of
the HELO/EHLO (the literal) and in my case user authentication, accessdb hash
table lookups on blackholed relays (in our case we delay checks thus need to
look at this inside the milter to be 100% effective), and so on, so as you
see, it is no where near based solely on the HELO/EHLO. Also, I have extensive
logged evidence that 550 rejects are what these messages actually do deserve;
all bare literals I have logged either ended up as user unkowns or
tagged/rejected as spam... _ALL_ of them. I think I am fully satisfying the
RFC in this regard as well.
So, while I think it may be a little draconian and that they are going to have
numerous issues with poorly coded MTAs... I think they are probably not in
violation of the RFC if they are doing any checking at all in conjunction with
the HELO/EHLO checks and not just pattern matching it and rejecting it. Now I
think the code we have posted that catches the bare literals is probably in
violation, in of itself... but since its implementation in MD still accepts
the bogus HELO and actually does not issue a reject until after the RCPT TO:
command (or MAIL FROM: if you run yours in filter_sender) I think we are still
in compliance with the RFC as well.
Anyway, still sifting some of this.. maybe I will change my mind but bottom
line is.. I think your Norton product is broke!
Jim
On Fri, 25 Mar 2005 11:43:24 -0600, Ben Kamen wrote
> I'm looking over it and the section reads more like 821 than 1123.
>
> I'm not trying to beat a dead horse - I'm just trying to make sure
> my interpretation of the "rules" are correct. Right now, Spam has
> everyone trying things of which some seem to break MTA's in a
> legitamate fashion while other methods are in a way vigalantism (if
> that's word)...
>
> How do you politely tell another admin he's broken something against
> an RFC when there's room for personal inflection of what the RFC is
recommending.
--
EsisNet.com Webmail Client
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT: New Sendmail spam block
David F. Skoll wrote: On Thu, 24 Mar 2005, Ben Kamen wrote: The person I've been having the problems with is quoting RFC821, but forgetting he's breaking RFC1123 which is the amendment to 821. The latest is RFC 2821. Thanks, I'm looking over it and the section reads more like 821 than 1123. I'm not trying to beat a dead horse - I'm just trying to make sure my interpretation of the "rules" are correct. Right now, Spam has everyone trying things of which some seem to break MTA's in a legitamate fashion while other methods are in a way vigalantism (if that's word)... How do you politely tell another admin he's broken something against an RFC when there's room for personal inflection of what the RFC is recommending. Anyway - thanks for everyone's input. -ben ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
