SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Do they reject them with a 55x error code or do they accept (code 2xx) and then silently delete them? Because the latter is not correct RFC-conform behavior. Transport errors must be reported back to the sending SMTP.
Accept and then silently delete. In fact, according to the report that the tech sent me, the detection happens even before the DATA phase of the SMTP transaction:
Code:
Feb 27 13:35:51 mailfe1 msd[10484]: Linux Magic SMTPD started: connection from 198.48.197.226
Feb 27 13:35:51 mailfe1 msd[10484]: Created UUID 216e9432-9ff7-11e3-b903-00259014b752 for message
Feb 27 13:35:51 mailfe1 msd[10484]: EHLO command received, args: AlphaBase.mvtech.ca
Feb 27 13:35:52 mailfe1 msd[10484]: STARTTLS command received, args: TTLS
Feb 27 13:35:52 mailfe1 msd[10484]: CONNECTED using SSL
Feb 27 13:35:52 mailfe1 msd[10484]: EHLO command received, args: AlphaBase.mvtech.ca
Feb 27 13:35:52 mailfe1 msd[10484]: MAIL command received, args: From:<no-harvest@mvtech.ca>
Feb 27 13:35:52 mailfe1 msd[10484]: Doing server-wide checks
Feb 27 13:35:52 mailfe1 msd[10484]: Done server-wide checks
Feb 27 13:35:52 mailfe1 msd[10484]: RCPT command received (198.48.197.226), args: To:<majordomo@slackware.com>
Feb 27 13:35:52 mailfe1 msd[10484]: IP country code[198.48.197.226] = "CA"
Feb 27 13:35:52 mailfe1 msd[10484]: domain country code[no-harvest@mvtech.ca] = "**"
Feb 27 13:35:52 mailfe1 msd[10484]: domain country code[AlphaBase.mvtech.ca] = "CA"
Feb 27 13:35:52 mailfe1 msd[10484]: Doing server-wide checks
Feb 27 13:35:52 mailfe1 msd[10484]: Done server-wide checks
Feb 27 13:35:52 mailfe1 msd[10484]: RCPT address [majordomo@slackware.com] is local
Feb 27 13:35:52 mailfe1 msd[10484]: User spam rules loaded successfully
Feb 27 13:35:52 mailfe1 msd[10484]: User spam checking enabled
Feb 27 13:35:52 mailfe1 msd[10484]: SPAM HIT: check_dynamic_reverse_dns
Feb 27 13:35:52 mailfe1 msd[10484]: Adding flag for quarantine.
Feb 27 13:35:52 mailfe1 msd[10484]: DATA command received, args:
Feb 27 13:35:53 mailfe1 msd[10484]: incrementing hop count
Feb 27 13:35:53 mailfe1 msd[10484]: incrementing hop count
Feb 27 13:35:53 mailfe1 msd[10484]: virus scan: /var/spool/qmail/mess/16/613771: OK
Feb 27 13:35:53 mailfe1 msd[10484]: virus scan: /----------- SCAN SUMMARY -----------/Infected files: 0/Time: 0.001 sec (0 m 0 s)
Feb 27 13:35:53 mailfe1 msd[10484]: Returning 250 ok [qp 10513] for data
Feb 27 13:35:53 mailfe1 msd[10484]: QUIT command received, args:
Feb 27 13:35:53 mailfe1 msd[10484]: Exiting (bytes in: 270 out: 320)
Well I got another reply from Succeed.net... basically a "this is how our server is configured and we're not changing it, go away" type of reply. Not that I am surprised or anything.
Well I got another reply from Succeed.net... basically a "this is how our server is configured and we're not changing it, go away" type of reply. Not that I am surprised or anything.
These lazy pals are the people who break reliable Internet e-mail for all of us, not the spammers. So the slackware.com MX is officially a black hole. BTW: It's perfectly valid to check various sending host requirements at the HELO/EHLO state and reject connections, just as AOL does. But I would never configure my own MX the way succeed.net did, because accepting and silently suppressing electronic mail can have legal consequences over here.
Well I got it working. I was able to take a few basic mail headers and put them in a text file, place my subscribe command a couple of lines later, copied everything to the clipboard, then on one of the mail servers that I look after at work (which is on a static IP and has a proper PTR DNS record) did a telnet to port 25 of cwo.mail.com, and did a manual SMTP transaction using my mvtech.ca email address in both the "MAIL FROM" SMTP command and the "From:" header in the fake message. Pasted my message after the DATA command, and the other side accepted it, and a few minutes later I got a delivery from Majordomo to mvtech.ca asking me to confirm my subscribe request. Changed the date header of my fake message (added a minute to the time) and copy/pasted the "auth ....... subscribe" command from Majordomo, telnetted again to cwo.mail.com on port 25, and they again accepted my message and Majordomo completed the subscription.
Just for fun afterwards, I sent a proper message from my mvtech.ca mail server to Majordomo, but did not receive a response; just wanted to see if Succeed.net had actually changed their DNS PTR rejection policy, but it appears not. So they accept a forged mail message from me, but reject a legitimate one... NICE!
Just for fun afterwards, I sent a proper message from my mvtech.ca mail server to Majordomo, but did not receive a response; just wanted to see if Succeed.net had actually changed their DNS PTR rejection policy, but it appears not. So they accept a forged mail message from me, but reject a legitimate one... NICE!
They don't reject anything, do they? They're just silently dropping it, right?
I recommend setting up an SPF record for mkvtech.ca to point to the actual IP address range of your outgoing mail relay. So at least correctly configured mail servers would reject this sort of forgery. There are also settings for finetuning MX and PTR checks.
They don't reject anything, do they? They're just silently dropping it, right?
Yes, that is correct... they do accept the message but then silently discard it. Sorry for the confusion.
Quote:
Originally Posted by jtsn
I recommend setting up an SPF record for mkvtech.ca to point to the actual IP address range of your outgoing mail relay. So at least correctly configured mail servers would reject this sort of forgery. There are also settings for finetuning MX and PTR checks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
