I am getting large numbers of these types of messages in my maillog files:
somehost.hotmail.com [65.54.246.97] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
on both of our external machines beginning on the same date. These hosts sit on different netblocks and on both machines the sendmail.cf files date from Jan 09, 2007.
The last successfull connection from any hotmail acocunt was on Jan 15 at 13:17:29. The first failure was recorded on Jan 15 at 18:36:46. Does anybody have any idea what is going on? We are now getting reports that hotmail users are getting a delayed transmission warning and then a failure message. Is this a sender's issue or our local configuration issue?
ANY help regarding this matter would be most appreciated. If you feel that sendmail related items should not be discussed on the list then please contact me privately.
Thanks, Jim
On 16/02/07, James B. Byrne byrnejb@harte-lyne.ca wrote:
I am getting large numbers of these types of messages in my maillog files:
somehost.hotmail.com [65.54.246.97] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
on both of our external machines beginning on the same date. These hosts sit on different netblocks and on both machines the sendmail.cf files date from Jan 09, 2007.
The last successfull connection from any hotmail acocunt was on Jan 15 at 13:17:29. The first failure was recorded on Jan 15 at 18:36:46. Does anybody have any idea what is going on? We are now getting reports that hotmail users are getting a delayed transmission warning and then a failure message. Is this a sender's issue or our local configuration issue?
ANY help regarding this matter would be most appreciated. If you feel that sendmail related items should not be discussed on the list then please contact me privately.
No idea, I thought the "did not issue MAIL/EXPN/VRFY/ETRN" error was largely due to zombied hosts injecting messages without waiting for the proper confirmation during the SMTP handshake, something we typically use GreetPause to work around.
Have you tried setting up a Hotmail test account and sending a mail to a known good account in your control to see if you receive any sort of bounce?
Will.
James B. Byrne wrote:
I am getting large numbers of these types of messages in my maillog files:
somehost.hotmail.com [65.54.246.97] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
on both of our external machines beginning on the same date. These hosts sit on different netblocks and on both machines the sendmail.cf files date from Jan 09, 2007.
The last successfull connection from any hotmail acocunt was on Jan 15 at 13:17:29. The first failure was recorded on Jan 15 at 18:36:46. Does anybody have any idea what is going on? We are now getting reports that hotmail users are getting a delayed transmission warning and then a failure message. Is this a sender's issue or our local configuration issue?
ANY help regarding this matter would be most appreciated. If you feel that sendmail related items should not be discussed on the list then please contact me privately.
It sounds like they are dropping the connection before getting very far in the conversation. This can be caused by either end, but the likely place to check is any spam-screening operations you might be doing that could impose a delay on your initial greeting, like having greet-pause set or using one of the network blackhole services that could be taking a long time to validate this address. Other places that can add delay are your reverse DNS lookup and an ident query on the socket. The latter can cause a long timeout if it hits a firewall that silently discards it without an ICMP 'denied' response.
On Fri, February 16, 2007 13:32, James B. Byrne wrote:
I am getting large numbers of these types of messages in my maillog files:
somehost.hotmail.com [65.54.246.97] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Possibly in relation to this problem I am seeing the following processes:
root 16758 1 0 13:17 ? 00:00:00 sendmail: server dslb-088-070-014- root 16996 1 0 13:23 ? 00:00:00 sendmail: server [41.248.11.84] cm root 17261 1 0 13:30 ? 00:00:00 sendmail: server cm90166.red83-165 root 17423 1 0 13:35 ? 00:00:00 sendmail: server saihou07.saisoft. root 17467 1 0 13:37 ? 00:00:00 sendmail: server imf20aec.mail.bel root 17517 1 0 13:38 ? 00:00:00 sendmail: server 71-37-44-219.tukw root 17529 1 0 13:39 ? 00:00:00 sendmail: server 203-144-153-222.s root 17633 1 0 13:41 ? 00:00:00 sendmail: accepting connections root 17634 17633 0 13:41 ? 00:00:00 sendmail: ./l1FKUT3v010731 mail.gi smmsp 17641 1 0 13:41 ? 00:00:00 sendmail: Queue runner@01:00:00 fo root 17715 17633 0 13:44 ? 00:00:00 sendmail: server 84-55-78-153.rev. root 17758 17633 0 13:45 ? 00:00:00 sendmail: server smtp5.mundo-r.com root 17781 17633 0 13:46 ? 00:00:00 sendmail: server saihou07.saisoft. root 17862 17633 0 13:48 ? 00:00:00 sendmail: server imf16aec.mail.bel root 17863 17633 0 13:48 ? 00:00:00 sendmail: server imf16aec.mail.bel root 17864 17633 0 13:48 ? 00:00:00 sendmail: server imf16aec.mail.bel root 17866 17633 0 13:48 ? 00:00:00 sendmail: server imf16aec.mail.bel root 17868 17633 0 13:48 ? 00:00:00 sendmail: server imf16aec.mail.bel root 17869 17633 0 13:48 ? 00:00:00 sendmail: server imf16aec.mail.bel root 17883 17633 0 13:48 ? 00:00:00 sendmail: server cc154194-a.haaks1 root 17906 17633 0 13:49 ? 00:00:00 sendmail: server 76.pool85-57-36.d root 17946 17633 0 13:50 ? 00:00:00 sendmail: server [200.21.164.14] c root 18014 17633 0 13:51 ? 00:00:00 sendmail: server host86-143-148-10 root 18167 17633 0 13:55 ? 00:00:00 sendmail: server 206-81-246-201.ad root 18219 17633 0 13:56 ? 00:00:00 sendmail: startup with simmts2-srv root 18224 17633 0 13:56 ? 00:00:00 sendmail: startup with [151.76.209 root 18226 17633 0 13:56 ? 00:00:00 sendmail: startup with mail.bis.eu root 18228 17633 0 13:56 ? 00:00:00 sendmail: startup with smtp.myclea root 18230 17633 0 13:56 ? 00:00:00 sendmail: startup with APoitiers-2 root 18231 17633 0 13:56 ? 00:00:00 sendmail: startup with host138-55- root 18234 17633 0 13:56 ? 00:00:00 sendmail: startup with c63314BC1.d root 18235 17633 0 13:56 ? 00:00:00 sendmail: startup with email-proxy root 18238 17633 0 13:57 ? 00:00:00 sendmail: startup with bay0-omc3-s root 18239 17633 0 13:57 ? 00:00:00 sendmail: startup with [151.76.209 root 18241 17633 0 13:57 ? 00:00:00 sendmail: startup with mta-c3.warp root 18242 17633 0 13:57 ? 00:00:00 sendmail: startup with BHE20013915 root 18243 17633 0 13:57 ? 00:00:00 sendmail: startup with smtp.myclea root 18244 17633 0 13:57 ? 00:00:00 sendmail: startup with [213.154.93 root 18245 17633 0 13:57 ? 00:00:00 sendmail: startup with cm117.delta root 18246 17633 0 13:57 ? 00:00:00 sendmail: startup with APoitiers-2 root 18247 17633 0 13:57 ? 00:00:00 sendmail: startup with aog206.neop root 18248 17633 0 13:57 ? 00:00:00 sendmail: startup with email-surro root 18249 17633 0 13:57 ? 00:00:00 sendmail: startup with dslb-084-06 root 18250 17633 0 13:57 ? 00:00:00 sendmail: startup with st64.startl root 18251 17633 0 13:57 ? 00:00:00 sendmail: startup with d-210-236-7 root 18252 17633 0 13:57 ? 00:00:00 sendmail: startup with mx06.bwc.na root 18253 17633 0 13:57 ? 00:00:00 sendmail: startup with smtp11-01.p root 18254 17633 0 13:57 ? 00:00:00 sendmail: startup with cm035.hic5. root 18257 17633 0 13:57 ? 00:00:00 sendmail: startup with 77-99-51-11 root 18258 17633 0 13:57 ? 00:00:00 sendmail: startup with [212.110.77 root 18259 17633 0 13:57 ? 00:00:00 sendmail: startup with 218.65.adsl root 18260 17633 0 13:57 ? 00:00:00 sendmail: startup with mail.bis.eu root 18261 17633 0 13:57 ? 00:00:00 sendmail: startup with BHE20013915 root 18262 17633 0 13:57 ? 00:00:00 sendmail: startup with 65-115-77-1 root 18265 17633 0 13:57 ? 00:00:00 sendmail: startup with adsl-084.22 root 18266 17633 0 13:57 ? 00:00:00 sendmail: startup with localhost root 18267 17633 0 13:57 ? 00:00:00 sendmail: startup with [24.218.14. root 18268 17633 0 13:57 ? 00:00:00 sendmail: startup with APoitiers-2 root 18269 17633 0 13:57 ? 00:00:00 sendmail: startup with 68-190-55-1 root 18270 17633 0 13:57 ? 00:00:00 sendmail: startup with c-24-0-176- root 18271 17633 0 13:57 ? 00:00:00 sendmail: startup with [84.52.106. root 18272 17633 0 13:57 ? 00:00:00 sendmail: startup with 240.50.124. root 18273 17633 0 13:57 ? 00:00:00 sendmail: startup with 29-121.124- root 18274 17633 0 13:57 ? 00:00:00 sendmail: startup with 200-180-9-1 root 18275 17633 0 13:57 ? 00:00:00 sendmail: startup with dyndsl-091- root 18276 17633 0 13:57 ? 00:00:00 sendmail: startup with NET-allocat root 18277 17633 0 13:57 ? 00:00:00 sendmail: startup with [213.156.11 root 18278 17633 0 13:57 ? 00:00:00 sendmail: startup with cm035.hic5. root 18279 16634 0 13:57 pts/0 00:00:00 ps -ef root 18280 17633 0 13:57 ? 00:00:00 sendmail: startup with 209.226.175
Which is an unusually high number for our organization. The other external MX machine is similarly loaded. Are these issues related to one another?
It sounds like they are dropping the connection before getting very far in the conversation. This can be caused by either end, but the likely place to check is any spam-screening operations you might be doing that could impose a delay on your initial greeting, like having greet-pause set or using one of the network blackhole services that could be taking a long time to validate this address. Other places that can add delay are your reverse DNS lookup and an ident query on the socket. The latter can cause a long timeout if it hits a firewall that silently discards it without an ICMP 'denied' response.
-- Les Mikesell lesmikesell at gmail.com
This indeed was the problem. One of the DNSBLS that we were using has discontinued operation (without notice to subscribers apparently). This was causing some MTAs to drop connections without issuing any commands to our hosts.
In the process of resolving this I also took the opportunity to implement Sapmhaus's DROP list as an access.db filter. This change together with blocking .BR and .RU tlds (with an informative error message on how to arrange connectivity to our servers) has cut out number of concurrent SMTP connections from an average of ~68 to ~8.
Regards,
-- James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
On Feb 19, 2007, at 11:54 AM, James B. Byrne wrote:
In the process of resolving this I also took the opportunity to implement Sapmhaus's DROP list as an access.db filter. This change together with blocking .BR and .RU tlds (with an informative error message on how to arrange connectivity to our servers) has cut out number of concurrent SMTP connections from an average of ~68 to ~8.
Do you mind sharing how you implemented the drop list as a access.db filter?? How did you represent the various network blocks??
Thank you,
-ed-
On Feb 20, 2007, at 11:46 AM, Edward Milstein wrote:
Do you mind sharing how you implemented the drop list as a access.db filter?? How did you represent the various network blocks??
Here's how I do it. This used to be in the completewhois.com tools section, but I can't find it anymore.
Requires Sendmail's cidrexpand. Apologies for the FreeBSD references....
#!/usr/bin/perl # # This script is used to convert list of ip blocks in cidr format into # script that can be run to setup linux firewall to filter those blocks # Script is written by William Leibzon for Completewhois Bogons Project: # http://www.completewhois.com/bogons/ # # $1 - should be list of ip blocks in cidr format # # Hacked up to format the drop list for feeding to sendmail's cidrexpand # script to provide a list of net ranges to feed to sendmail's access table. # The cidrexpand script is available in the contrib directory of your # sendmail distribution. (/usr/src/contrib/sendmail/contrib/cidrexpand # on FreeBSD.) # # Thanks to William Leibzon for the original script and Eric Kagan and # Steve Glines for the inspiration. # --Chris Boyd cboyd (at) gizmopartners 1-2-05 # # Recommended usage: # droptosend <droplist> | cidrexpand | sort | uniq # (cidrexpand has some odd bugs that cause it to make duplicate lines)
$cidr_filename=@ARGV[0];
if ($cidr_filename eq "") { print "Usage: droptosend cidr_list_file\n"; exit; } open ($cidr_fh, $cidr_filename) or die "can't open file $cidr_filename: $!";
while (<$cidr_fh>) { $line=$_; ($ip1,$ip2,$ip3,$ip4,$mask) = /^(\d{1,3}).(\d{1,3}).(\d{1,3}). (\d{1,3})/(\d{1,2})/; if ($ip1 ne "" && $ip2 ne "" && $ip3 ne "" && $ip4 ne "" && $mask ne "") { print "$ip1.$ip2.$ip3.$ip4/$mask ERROR:5.7.1:550 see http://www.spamhaus.org/drop/%5Cn"; } }
Question for the group,
While I appreciate the excellent answers thus far and I always appreciate the support from this group,
Why implement this block as an access.db instead of a route add x.x.x.x/24 reject??
One reason might be dropped routes generate no logging..
If some address space is removed from the spamhaus droplist, than do you manually remove it from access.db list??? How do you know if it was removed?? Is address space ever removed??
Sorry but might be a better discussion for a sendmail list!! ;-)
-ed-
On Feb 20, 2007, at 2:17 PM, Chris Boyd wrote:
On Feb 20, 2007, at 11:46 AM, Edward Milstein wrote:
Do you mind sharing how you implemented the drop list as a access.db filter?? How did you represent the various network blocks??
Here's how I do it. This used to be in the completewhois.com tools section, but I can't find it anymore.
Requires Sendmail's cidrexpand. Apologies for the FreeBSD references....
#!/usr/bin/perl # # This script is used to convert list of ip blocks in cidr format into # script that can be run to setup linux firewall to filter those blocks # Script is written by William Leibzon for Completewhois Bogons Project: # http://www.completewhois.com/bogons/ # # $1 - should be list of ip blocks in cidr format # # Hacked up to format the drop list for feeding to sendmail's cidrexpand # script to provide a list of net ranges to feed to sendmail's access table. # The cidrexpand script is available in the contrib directory of your # sendmail distribution. (/usr/src/contrib/sendmail/contrib/cidrexpand # on FreeBSD.) # # Thanks to William Leibzon for the original script and Eric Kagan and # Steve Glines for the inspiration. # --Chris Boyd cboyd (at) gizmopartners 1-2-05 # # Recommended usage: # droptosend <droplist> | cidrexpand | sort | uniq # (cidrexpand has some odd bugs that cause it to make duplicate lines)
$cidr_filename=@ARGV[0];
if ($cidr_filename eq "") { print "Usage: droptosend cidr_list_file\n"; exit; } open ($cidr_fh, $cidr_filename) or die "can't open file $cidr_filename: $!";
while (<$cidr_fh>) { $line=$_; ($ip1,$ip2,$ip3,$ip4,$mask) = /^(\d{1,3}).(\d{1,3}).(\d{1,3}). (\d{1,3})/(\d{1,2})/; if ($ip1 ne "" && $ip2 ne "" && $ip3 ne "" && $ip4 ne "" && $mask ne "") { print "$ip1.$ip2.$ip3.$ip4/$mask ERROR:5.7.1:550 see http://www.spamhaus.org/drop/%5Cn"; } } _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Feb 20, 2007, at 3:53 PM, Edward Milstein wrote:
Why implement this block as an access.db instead of a route add x.x.x.x/24 reject??
If you drop the packets, the sending server will queue the message for 4 or 5 days before returning it to a hypothetical live user. By doing the 5xx message the live users will get the bounce message almost immediately (as should the postmaster) and take action to get delisted.
If some address space is removed from the spamhaus droplist, than do you manually remove it from access.db list??? How do you know if it was removed?? Is address space ever removed??
I just download the list periodically and regenerate the access.db. You can diff it if you like. That takes care of the first two. Yes, Spamhaus does remove addresses from the list periodically.
Sorry but might be a better discussion for a sendmail list!! ;-)
Could be.
--Chris
Edward Milstein eddiem5 at yahoo.com
* Previous message: [CentOS] Re: Problem with some SMTP MTAs * Next message: [CentOS] ASUS M2V mobo issues * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue Feb 20 17:46:15 UTC 2007, Edward Milstein eddiem5 at yahoo.com wrote:
Do you mind sharing how you implemented the drop list as a access.db filter?? How did you represent the various network blocks??
No. I don't mind, but the resulting access file is about 1650 lines long and would be of no interest to anyone who does not run sendmail. If you desire then I will send it to you as an attachment.
the access.db does not handle CIDRs so one has to convert the DROP list to all of the included B or C netblocks. For example something like A.B.64.0/21 would result in access entries:
# A.B.64.0/21 - Spamhaus DROP entry A.B.64 REJECT A.B.65 REJECT A.B.66 REJECT A.B.67 REJECT A.B.68 REJECT A.B.69 REJECT A.B.70 REJECT A.B.71 REJECT
Regards,
-
Chris Boyd -
Edward Milstein -
James B. Byrne -
Les Mikesell -
Will McDonald