| Re: FORMS, validating mail was sent [message #181925 is a reply to message #181918] |
Mon, 24 June 2013 19:43   |
gordonb.4qaft
Messages: 1
Registered: June 2013
Karma:
|
Junior Member |
|
|
>> + Your mail was dropped on the floor for having an invalid
>> From: address. Valid From: addresses likely include ONLY
>> those with the host name of the server you are sending
>> from and a known valid user on that system. Typically
>> only a few users like root can send mail with 'fake'
>> (off-system) From: addresses. Hint: Do NOT put a
>> user-supplied email address in the From: header.
>
> Utter nonsense. By that logic, Web-mail like GMail could not possibly work,
> and it would not be possible to have large e-mail providers in the first
> place (because the host name of their servers very likely differs from the
> domain of the From header field address).
I certainly hope that a self-described "near newbie" is not going to try
to implement something of the scale of Gmail.
A self-described "near newbie" is not going to know all the issues
in properly validating things that go into mail headers. I won't
encourage them to put up email forms (or try do-it-yourself parachute
packing and skydiving) until they learn more.
> Valid From addresses include all that meet the Address Specification in
> RFC 5322, instead. This is a purely *syntactical* determination. It is the
> fact that even addresses for which there are no mailboxes at the sending
> server can be used in the From header field value, and that afterwards
> checking of addresses is unreliable, that allows spammers to thrive.
From the point of view of sendmail, which is used by default setups in PHP
(except for Windows), there are other requirements. Sendmail doesn't like
local users to forge mail in the name of other users.
> One must differentiate between the address used as parameter for the MAIL
> FROM (SMTP) command (the “Envelope-From”), and the “From” Internet message
> header field. The latter can be anything; the former can, in theory, be
> anything unless the *sending* MTA enables counter-measures. It is not
For many default setups, the sending MTA enables countermeasures. This
can be turned off but not if you are stuck with an unsophisticated hosting
company that likes to leave settings at the default.
For some, the receiving MTA enables countermeasures and checks *BOTH* the
From: line and the envelope sender to the extent that it can (which usually
means that the domain exists, has an MX or A record, and it doesn't point
to 127.0.0.1. However, if the MTA also hosts the sender domain, the
check can verify the mailbox exists).
Exim also has "sender verify" (which can be optionally enabled).
On starting to receive an incoming message, Exim starts to send a
bounce message back to the envelope-sender. If the bounce message
is refused (at the MAIL FROM: and RCPT TO: stage), so is the message.
The bounce message is never completely sent (and has no text) so
it's never delivered. If sender DNS or mail server goes down, the
message goes nowhere.
> possible to change the Envelope-From with simple PHP commands like mail() as
> that is determined by the MTA (like sendmail) used by the PHP executable.
> The only good part of this answer is the notion that you invite spammers if
> you let the end user specify the From header field address without
> authentification; so you should not do that, indeed. The /modus operandi/
> of spammers and phishers is to harvest or buy e-mail addresses from various
> sources and use them also in the “From” header field value to make the
> message look to the recipient like a legitimate e-mail (at first). This
> kind of network abuse is also supported by “open relays” – MTAs that would
> accept and transfer mail for any MAIL FROM to any RCPT TO.
They also use header injection, so that poorly written contact forms
can be misused (like an open relay) to send to lots more victims
than just the webmaster of the site. Spammers like that even if
they can't control the From: line.
>> + The intended recipient has a slow DNS server. If you
>> send emails to 100 recipients at a time, it is likely
>> that at least a couple of them have slow DNS servers or
>> overloaded mail servers. The mail will stay in the queue
>> until the message has been delivered to all recipients,
>> and that can take days, even if 98 of them were delivered
>> in the first minute.
>
> Utter nonsense. DNS is only used to resolve the target host of the message,
> specifically to retrieve the host name from the “MX” or “A”/“AAAA” record of
> the target domain, and subsequently to resolve the IP address for that host
> name from its “A” or “AAAA” record (this double-handshake is intended as a
> safety feature of DNS/SMTP: there must be a host *name* for an MX). There
> are no DNS servers anywhere that have a respond time of minutes that would
I suggest that nobody would know that, since software doesn't wait
that long for a response - it just gets treated as a nonresponse.
However, there are a fair number of DNS servers that don't answer,
perhaps because they are on the far end of a loaded DSL line. At
any given time there are DNS servers that are down or unreachable
because of hardware failure, loss of network connectivity, or power
failure.
I hope that the company net admin who said he shuts down his
nameservers and mail servers on weekends, holidays, and overnight
has changed his mind.
The fact that BIND (and some other nameserver software) has memory
leaks and over time will start paging more and more when presented
with an ISP-level load doesn't help. Neither does putting your
nameserver and your mailserver on the same host.
> suggest the remote possibility of a delay of days because of DNS issues
> (after all, a backup DNS server is strongly recommended, and there are non-
> authoritative answers).
Some people seem to think a backup DNS server can be accomplished
with a CNAME record pointing ns2.mycompany.com to ns1.mycompany.com.
Or putting two nameservers at the far end of the same DSL line. I
think if your net presence is important to you, you should have at
least 3 different nameservers on 3 different continents, but for
many companies that's overkill. Hmm... how long before it's practical
to put DNS servers on 3 different planets?
About non-authoritative answers: those can cause mail to be delayed
indefinitely (until a mail server gives up completely, or someone
manually fixes the problem). If my mail server's nameserver doesn't
have the destination domain in it's cache, it asks the root servers,
which probably refer it to the appropriate registrar's servers,
which may refer it to the hosting company's servers, which give it
the MX host. The problem comes when the registrar's servers give
a referral to a DNS server that gives a non-authoritative no-such-domain
error (or worse, isn't up yet). The MTA considers this a retryable
error. This problem usually arises (at least briefly) when you
first set up a domain, or change hosting companies for your DNS.
It can extend for a long period (e.g. weeks or years) if someone
botches the move and nobody notices. Perhaps even worse is the
case where *half* of the registrar's nameservers point to the
wrong place - it may look fine to the domain admin, but not work
for half the world trying to send mail in.
Back in the time frame of 1998-2004 there was a TOP-LEVEL DOMAIN
that was consistently pointed at an unreachable nameserver for a
period of at least 5 years. I think it was .et (Ethiopia). Or
maybe .nt (Neutral Zone - and not the one between the Federation
and the Romulan Empire). Some people would get long-delayed bounce
messages because they had left a letter out of a .net address.
> When in rare cases e-mails arrive days later, it is usually due greylisting
> and a long sender or receiver message queue that needs to be worked through;
> not DNS issues at the receiver's (BTST). Also, the mail queue contains a
> *copy* of the message for each recipient (not least because in the worst
> case each copy must be sent to a different host). Only those copies that
> have not been sent are still in the queue, not the single original message
> (“the mail”) itself.
Many MTAs are much smarter than that (if you hand them one email
with multiple addresses). Some of the stupider MTAs use one queue
copy per destination domain in the list (granted, for some mailing
lists, this is almost equivalent to one per addressee). Some might
use one per set of destination MX records (so if two domains are
hosted on the same server, only one copy is sent). Exim, and I
believe sendmail also, uses one copy, period. (Of course, it can't
always get away with *sending* only one copy.) Control information
is kept which indicates which addressees have completed deliveries.
By looking at a verbose queue listing, I can find how long the
message has been sitting in the queue, and which addresses are
having problems.
I was seeing the long-delayed messages in the outgoing queue. I
also don't claim that the problem addresses were all correct. There
was the *.et problem, and email addresses where the domain was still
up but the company mail server had been auctioned off with other
company assets.
> “Overloaded mail servers” also are unlikely to be a reason why a message
> stays in the sending queue, because receiving MTAs *also* have an *incoming*
> message queue which is worked through to put the message into the
> corresponding receivers' mailboxes.
An overloaded mail server can be unable to respond to a new connection
in time (5 minutes is a typical timeout) for reasons such as heavy
paging/swapping, so the sending server gives up and tries later
(which makes the problem worse). Sometimes this is an "inrush"
problem: a server that's been down for hours gets hammered when it
comes back up. If you don't have limits on the number of incoming
connections, you can run out of swap space or TCP buffer space.
Sometimes the server needs to deliberately ignore incoming connections
so it can finish up with the ones it already has.
> Overloading is more likely the reason
> why the message does not arrive at the recipient's mailbox sooner, but that
> has nothing to do with the message transfer between the MTAs, and nothing
> with the sending MTA's outgoing message queue.
If a mail server can consistently (even if slowly) accept mail for the
queue, I don't call it overloaded, although there may be a problem with
the queue building up. Heavily loaded, yes.
>>> But you cant execute that without root privileges. Which means having
>>> that level of access to the machine and writing an su 'ed wrapper in C
>>> and calling that instead.
>>
>> Sometimes you can get a queue count without root privileges. The
>> program that comes with the MTA for this is likely already setuid-root,
>> and you may be able to configure allowing ordinary users to get a
>> queue count.
>
> man sudo
I prefer a MTA-supplied solution over sudo, *if* there is one.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]